Hi Soren, My thought is that a good solution may be to make a build/check script that would generate the compressed package file, the HTML, run all tests, and maybe upload everything to the sf svn.
As I understand the current state of things, all but the upload is either done by some tool or easy. Do you think that a tool like this would be both simple to make/maintain and use? Have a good day, Bill On Dec 22, 2008, at 4:42 PM, Søren Hauberg <so...@hauberg.org> wrote: > Hi All, > I'll start out by summarizing the current situation: the Octave-Forge > release system sucks! So, why does it suck? Let's look at the current > release procedure. > When $my_package has been changed, the maintainer needs to wait until > the release manager (that would be me) decides to make a new > release. At > that point the release manager runs a set of scripts that creates all > packages, and compares them with the ones that are currently uploaded. > Any packages that has been changed since the last release are then > flaged as being changed. These packages are then uploaded manually to > Sourceforge. All packages are then used to generate the web pages, > which > are then uploaded manually to Sourceforge. > So, what's the problem with this approach? > > 1) Package maintainers are not in control of when their package is > released. This is also a problem when new packages are added to the > list. They are only available to users after the next release. > > 2) The system has some bugs that incorrectly flags some packages as > being changed, even though they haven't been changed. This creates > more work for the release manager, but also for distributions that > has to update their packages. > > 3) The current code for generating the web pages is quite a mess. At > this point, it is practically impossible to make changes to anything > related to the web pages. > > 4) If some problem occurs during the package creation, the release > manager has to fix the issue. Since the release manager doesn't > really know the code as well as its maintainer, he really isn't the > right person to fix the issue. > > I'm probably forgetting some issues here, so feel free to remind me of > other issues :-) > So, what can we do to improve the situation? In the long term I think > we should have our web site integrated with www.octave.org, as this > will > make things easier for users, and will be less work for us. However, > doing this is a large task, and I'm not sure what such a move > requires. > So, for now I think we should try to improve the situation within the > limitations of the setup that Sourceforge provides. The main > limitation > of Sourceforge is that some privileged user has to manually upload the > packages. > What I suggest is that package maintainers makes the releases. The > only thing they wont be able to do is to upload the packages and web > pages to Sourceforge. That is, when a maintainer decides to make a > release he/she creates the package file, and the relevant web pages. > These files should then be made available to a privileged user who > then > uploads them to Sourceforge. This is still a bit tedious and could be > automated, but I don't think it can be improved within the limitations > of Sourceforge. > So, any thoughts on the situation? I'm open to alternative solutions, > but I think we, in the short term, need to limit ourselves to what > Sourceforge can do. > > Søren > > > --- > --- > --- > --------------------------------------------------------------------- > _______________________________________________ > Octave-dev mailing list > Octave-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/octave-dev ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
