Neil Hopcroft

Following a discussion on the maintainers mailing list about some recent problems with sourceforge, the Octave Forge packages are moving away from the sourceforge version control system. I have, for a while, been thinking about restructuring my octave-packages project. The current structure has two layers, one for the svn code from sourceforge, then a second with a number of mercurial projects. From a CI build point of view, only the svn repository is checked for changes, although whenever a build is made the mercurial packages are updated.
According to the octave forge webpage, the svn repository still exists, although it is now mostly a place for unmaintained code. There is also now some new packages using git.
Now I’m thinking about switching over to a bunch of projects, one for each octave forge package, as well as keeping the first layer of the current set up for the svn packages. This would make the whole thing a bit more manageable as the current build takes hours, nothing is properly cleaned and everything gets rebuilt whether it is needed or not. One of the big problems is that the octave-packages project has a dependency on dolfin, which gets a lot of updates, meaning there are lots of rebuilds requested. Moving to individual packages would mean that could be cut down to a single package being rebuilt for every dolfin build.
The octave forge packages also have their own dependency map, which could then be reflected in the build structure.
It is going to take quite a lot of setting up to get the new projects arranged and building, but it should make for clearer builds. What is going to get more complicated, though, is collecting the test results, since that is currently done at the end of the octave-packages build. What I could do would be to keep the current test code and move that to a project that runs daily.