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
