Re: Octave-Forge bugs in the tracker?

[Jordi Gutiérrez Hermoso]

2011/7/24 c. <address@hidden>:
>
> On 24 Jul 2011, at 17:12, Jordi Gutiérrez Hermoso wrote:
>
>> 2011/7/24 Thomas Weber <address@hidden>:

>>> For the record, I disagree with a lot of things that people here
>>> seem to take for granted:
>>
>> My bad. Forget I said anything. There isn't a problem that needs to
>> be fixed and everything is fine as it is. Sorry.
>
> Personally I believe there is a lot that can be fixed or at least
> improved and there always will be and that discussion on this topic
> should be highly encouraged, please don't stop proposing new ideas.

Okay, fine, if you insist...

On 24 July 2011 11:51, c. <address@hidden> wrote:
> I agree that having one separate repository for each separate
> package makes no sense.

Why not? Essentially they are already like that. The single svn
repository for all of them isn't effectively any different than having
a single hg repo per package, with a larger hg repo containing all of
the packages as subrepos. Checking out a single svn directory to work
on a package you care about would be functionally equivalent to
cloning its hg repo.

Besides the packages themselves, the single svn repository mostly
contains stuff for the monolithic releases that hasn't been used in
years. If 'Forge isn't monolithic, why should its VCS be?

> As Søren noted, developement of some packages happens mostly
> elsewhere, so having as a requirement for distributing a package via
> OF that the code be in the repository seems a bit awkward.
>
> It used to make sense when monolithic releases were being built
> automatically by makefiles in the repository, but why should we
> still force that now? Although there is no hard evidence that this
> would attract more contributors, I know for sure it would attract
> more packages, I myself am developing some projects where having a
> separate VCS repository and website is a requirement but
> distributing packages via different channels would not be a problem.

I don't understand. Do you want developers to choose whatever resource
to distribute their packages, like github or bitbucket? We need some
centralisation, and all packages should have some sort of uniformity,
shouldn't they? Should Octave-Forge just become a webpage with links
to people's Octave packages?

> P.S. Is the octvae-maintainers list the best place to hold this
> discussion? shouldn't it be held on the octave-forge mailing list?

This is precisely the sort of question that I wish wasn't necessary.
The two projects are so entwined that they are almost the same people.
Perhaps not the same people developing them, just as within Octave a
person might specialise in only some part of the code, but keeping us
in separate mailing lists without talking to each other isn't
beneficial, and in the end it's rare for people working on packages to
not also follow Octave development, at least from a distance.

People who make Octave-Forge packages have to be aware if something
changes in Octave, or if functions move from Octave-Forge to core, or
if the API changes, and Octave can't go changing things around
willy-nilly if this breaks Octave-Forge packages. Users will complain,
and they don't care if the package or if Octave core should be fixed.
This is an internal administrative detail that we shouldn't expose.

Also, you mentioned earlier that people get told when using Matlab
"buy another toolbox". I have not observed the majority of Matlab
users to do that. They almost always are introduced to Matlab through
site-wide licensing agreements with their university or sometimes
workplace (and very often simply disobey its license) and just use
Matlab functions without paying any attention if they're in a package
or not. As such, users don't care if whatever function they use is in
a package or in core, neither in Matlab nor in Octave. We can have
some separation for the convenience of developers, but I think it
should be essentially encapsulated. Users shouldn't have to care too
much about which bugtracker to report bugs to, or who is the
maintainer of the package that happens to contain their functions.

Basically, all I'm proposing here is that if reduce barriers to entry
and we use a uniform platform for development, we could have very
beneficial cross pollination between Octave and 'Forge.

- Jordi G. H.