Hi, > By the way, there is a good risk that Nicolas won't be able to > answer his e-mail before this evening. So don't expect more > feedback.
Yup; just back from a day of driving around! On Thu, Jun 03, 2010 at 09:07:45AM +0200, Florent hivert wrote: > > It would make great sense to have another Sage release before June 14. > > I don't want to be the one to make it. If you really want one that > > definitely has the combinat stuff correctly merged in, perhaps you > > could be that release manager, taking the 4.4.3 release as a start? > ... Well, yes, Florent and I are quite overloaded already, but that's still a fair question to ask. There definitely is strong virtue in rotating the load of this exhausting task on as many people as possible. And I appreciate that William took on the task several times recently, when he sure has as loaded an agenda as we have. So yes, I several times considered managing one release. However, thinking twice about it, I ended up to the conclusion that I should focus on the Sage-Combinat queue, because that's where I am most useful and efficient to the Sage community. A good part of what we are doing there is really prerelease management: early integration tests and conflict resolutions, so as to get stacks of conflict-free patches ready for merging. Which should me as much load taken off the release manager. Well, actually we just failed in doing so: > Unfortunately #8881 was bumped because the dependency on #9104 was > not mentioned. Let's analyze what happened and see how we can improve our process to prevent this from occurring again. Since a couple weeks, with Florent and a couple others, we are using a script (available upon request) that makes it a breeze to launch all tests on our build host (massena) with all Sage-Combinat patches up to a given one. I just type on my own machine: sage-combinat-test 8811 and 10 minutes later I receive by e-mail a summary of the full Sage test results, with all patches applied up to trac_8811_reduced_word_of_translations-nt.patch; the full log are posted on the web. Well, it's really just a trivial shell script not worth bragging about. But it literally changed our life by finally making it possible to review patches at about the same rate as we produce them. Automatizing the "all test pass" check is *the* key to solving the current patch review bottleneck in the Sage workflow, and this little script is more or less doing the job for us. There is an issue though in our workflow: it is possible, but currently not trivial, to only apply a couple selected patches; this means that, more often than not, we run the tests not only on the chosen patch, but also on all the ones that are before in the queue (which currently means those 25 that already have a positive review!). The consequence is that we don't easily detect dependencies like the one above. Ideally, we should add a feature to the script so that we could do: sage-combinat-test 9104 8811 and have the test run with only those patches applied. In the mean time, I propose the following: when we run the tests before setting a positive review on `trac_..._blah.patch`, we should run the tests up to exactly this patch in the queue, and then systematically post on trac a comment of the form: All tests passed on massena with the following patches applied: trac_8500_transitive_groups-final.patch trac_8549_cycle_enumerator-nb.patch ... trac_..._blah.patch This should give the release manager a good hint on the order the patches should be applied in. Cheers, Nicolas -- Nicolas M. ThiƩry "Isil" <nthi...@users.sf.net> http://Nicolas.Thiery.name/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org