Hi, First of all, I agree with the idea of replacing the release manager with individual package releases. It's annoying for maintainers to be waiting on the release manager, and it is simply annoying to be the release manager. When ever a release is made several things happen:
1) The individual packages are put into tar.gz files (one for each package). 2) The bundle is created. 3) The web pages are updated. 4) SVN is tagged to mark the release. 5) Files are uploaded to SF. The release scripts probably do some other stuff as well, but these points seems to be the most important ones. 1) and 4) could easily be handled by anybody with write-access to SVN (i.e. any package maintainer). As long as the number of maintainers is fairly low, I guess we could let individual maintainers upload their package to SVN. But in the long term we would probably need a better solution to 5). IMHO the bundle is a nice service that we should do our best to keep providing, but I don't think it should be a show stopper. So, for now I suggest simply forgetting the bundle. I'm sure we can set up a scripts that recreates the bundle once a day or something like that. And, if that's not possible, I guess we could provide a script that downloads all packages. So, that leaves point 3), i.e. creating the web pages. I think this (seemingly trivial) issue will actually be the one causing most problems. Currently, the web pages are generated by several scripts written in perl, python, shell, (octave?), and Make. These are pretty much a collection of dirty hacks that have been collected over the years. These scripts make all sorts of assumptions, and they generate the entire web site, and not just individual pages. So, I think these scripts need to be rewritten in one language, and in a much more general setting. I don't think it will be possible to get rid of the release manager until we have a solution to this part, but I haven't really thought this through... Søren søn, 31 08 2008 kl. 17:06 +0200, skrev Thomas Weber: > Hi, > > as part of a recent discussion[1] on the Octave mailing list about > merging Octave and Octave-Forge, the workload of the release manager > came up as a topic. > It's simply a lot of work to release a version of octave-forge; at the > same time, individual package maintainers might want to release their > package when it's ready and don't want to wait for release managers. > > I've implemented a prototype of a new release system; the basic idea is > that the first line of a check-in message is scanned. When it fits the > schema: > Release: DIR > a release of that individuall package is triggered. DIR is the path name > of the package's directory, i.e. "physical-constants" for the > "PhysicalConstants" package (that example already shows the difference > between filesystem and package name). > > Triggering a release means copying the source tree, running configure > and building that single package. It generally seems to work. > > Advantages: > a) Individual maintainers can release their package whenever they deem > it fit. > b) Creating a bundle boils down to taking the latest released packages > and tarring them up. > > > Problems (and there are quite of them): > I did this using a (converted) Mercurial archive of the octave-forge > Subversion tree. The scanning is triggered by an "incoming" hook. > Looking at [2], it seems SF provides a few hooks for the Subversion > repositories, but none of them fits trivially (both svnnotify and > ciabot don't really fit). It might be possile to track the SF > Subversion repository via hgsvn, so that problem is definitely solvable. > Another problem: to create packages, we need Octave installed on the > build host. > > Both things taken together mean that we generat the packages on a host > outside of SF; tracking the repository via hgsvn should be possible. > Now, one problem: how to get the built packages back onto the SF host? > > Following [3], uploading the files in an automated way seems possible. > However, I'm at a loss with the actual release via the SF mechanism. > > > [1] http://thread.gmane.org/gmane.comp.gnu.octave.maintainers/10837 > [2] > http://alexandria.wiki.sourceforge.net/Subversion+-+Version+Control+for+Source+Code#tocSubversion > - Version Control for Source Code15 > [3] > http://alexandria.wiki.sourceforge.net/File+Release+System+-+Offering+Files+for+Download#upload > > Thomas > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Octave-dev mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/octave-dev ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
