On 24 Jul 2011, at 20:43, Jordi Gutiérrez Hermoso wrote: > On 24 July 2011 11:51, c. <[email protected]> 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. ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
