octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave-Forge bugs in the tracker?


From: c.
Subject: Re: Octave-Forge bugs in the tracker?
Date: Sun, 24 Jul 2011 23:28:10 +0200

On 24 Jul 2011, at 20:43, Jordi Gutiérrez Hermoso wrote:

> 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.

that's why I think it makes no sense, it would add no extra functionality as 
compared to what can already be done, why take the effort then?
furthermore some packages are comprised of very few files, e.g. 
physical_constants is essentially one single file,
setting up a separate repository for such small packages seems like overkill.

> 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?

well, the repository does need a bit of cleaning up, some stuff is
probably there mostly because no-one had the time to check whether it still is 
needed.
On the other hand I see no reason why things that are not packages should not 
be kept in the repo.

> 
> 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?

no, that's not what I had in mind, what I meant is that a VCS is usually needed 
when doing
collaborative development, but some packages are not developed collaboratively, 
maybe rather 
than checking their code into the repository the developers of such packages 
could just upload
the package at release time? rather than github or bitbucket what I had in mind 
was to make
Octave-Forge more similar to CPAN or CTAN, except for the fact that COAN sounds 
funny ;)

 
>> 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?
> 
> 
> 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.

Actually that's what happens in academia, but every now and then I am forced to 
use Matlab
for some industrial project and in such case I get very specific instructions 
as to which 
toolboxes I can use and which I cant use.

And I don't think Mathworks would ever respond to support requests regarding 
third-party developed toolboxes.

> 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.

I think that's exactly what a clear separation of the projects intends to 
avoid. 
Entry barriers on Octave-Forge are kept low in order to encourage 
contributions. 
Not many constraints are imposed in terms of coding standards, generality or 
matlab compatibility.
Most packages uploaded to OF are stuff that someone developed for their own 
needs and then decided to 
share with others. If requested to make lots of modifications before committing 
their code they would mostly just give up.

That's not the approach taken in Octave-core where, e.g.,  matlab 
incompatibilities are treated as bugs.
Do you think it would be an efficient use of resources to have Octave-core 
developers
to take care of complaints about some functions for some very niche application 
in some
forge package being not matlab compatible? The standard response of "that's a 
function
from an OF package please contact the package maintainer" seems like a good way 
to avoid this.
 
> 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.

I agree that entry barriers should be kept low, but for that to be possible
a good separation is required in order to reduce the burden on the core 
developers.

> - Jordi G. H.
c.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]