Hi, On Tue, 13 Oct 2009 23:21:37 -0700 William Stein <[email protected]> wrote:
> What is "release management"? Right now there are *66* tickets > listed as "positive review" right here: > http://trac.sagemath.org/sage_trac/report/11 > > Definition: Release management is the process of taking these tickets, > applying them, bouncing those that don't work, creating a sage-4.2.tar > that works on our supported platforms, and creating binaries. If an > unacceptable number of patches bounce, we delay the release until the > relevant tickets are rebased. This is a great summary of the tasks in the release process. Robert Bradshaw said: > Of course the > problem is that we don't find the failures until well after the > stuff is merged, so just hunting down why something broke is > time-intensive. (I don't have a full answer to this, but more > automated testing on a wider range of platforms could go a long way > here...) If this phase weren't such a big deal, then the commitment > would be reduced, and one could actually do quick releases As Robert points out we can automate most of these tasks. A script can go through the patches with positive review on trac, merge them, test the result on different platforms, keep the patch if there are no failed tests, or bounce it back with an error report otherwise. This doesn't say anything about merging new packages, for now let's leave that out for simplicity. The only problem I see with this is that anybody can mark tickets "positive review" on trac. We don't require referees to know Sage conventions, or have an overview of design/technical issues with the library. IMHO, getting another approval from people more experienced with these is important. I don't mean another "review" by a referee, just looking over the code to make sure it looks good. Rob's suggestion would ease the load on any one person by delegating a few people to do this job. (This is also what Craig is saying with his suggestion of rotating the release manager even between alphas.) The status of "lieutenant" is the equivalent of having "commit access" in other open source projects. I would prefer a different term for "lieutenant", but I don't have anything better now. Rob Breezer said: > I wonder if the "lieutenant" model used by Linux kernel development > might be helpful here? If there was one or two people (lieutenants) > responsible for each broad area of Sage, and trusted to merge patches, I suggest the following process: - referee marks ticket positive review - a lieutenant looks over the patch, - either approves it - or points out problems and marks it "needs work" - on approval ticket goes in a queue for merge - a script goes through the queue, - merges the patch on the current tree - compiles & runs doctests on different platforms - if the tests pass, the patch is kept - otherwise, it is removed, and marked "needs work" on trac with a summary of failing tests by platform Comments? Cheers, Burcin --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
