2011/7/24 c. <[email protected]>: > > On 24 Jul 2011, at 17:12, Jordi Gutiérrez Hermoso wrote: > >> 2011/7/24 Thomas Weber <[email protected]>:
>>> 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. <[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. 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. ------------------------------------------------------------------------------ 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
