Hi! Part of the problem seems money. IIRC there is some funding by Google and by Sun. Can this be used to pay release management?
On Oct 14, 6:28 am, Rob Beezer <[email protected]> wrote: > [...] > 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, > maybe they would be constantly/frequently moving patches into a tree > that the release manager could pull from with confidence. I am by no means experienced in running a big project, but this model seems quite reasonable to me. And if it works for a project like Linux, why not for Sage as well? Please excuse if the following ideas are blatantly stupid. Applying the "lieutenant" model means to break up the release problem into various sub-problems. If I understood the posts in this thread correctly, steps currently done by the release manager are (1) does the patch apply? (2) does it break doc tests on any supported platform? (3) produce a release candidate, that is tested by the community (4) produce binaries. (1) should not be much of a problem, because the ticket's referee *has* applied the patch (hopefully). (4) is, I guess, automated. I don't see how the creation of a release candidate can be distributed, but testing of the candidate already is. So (2) would be the real problem, as probably it is impossible to run *all* tests on *all* platforms after applying any single patch. But I think this can be distributed to some extent. For sure, the different parts of Sage (group theory, commutative algebra, combinatorics, interfaces, ...) are interrelated. However, these parts *are* identifiable parts of Sage. It is a reasonable guess that, if a patch from a "commutative algebra" ticket breaks anything, then it is most likely to break something in the commutative algebra part (the exception proves the rule...). I suggest: - Create "partial test suites", that cover only one of the parts of Sage. But such partial test suites would be less time consuming. - Let them be used by release sub-managers (lieutenants), and they would probably catch *most* errors. - For each part of Sage, a sequence of patches results that seem fine when restricted to that part. - The lieutenant forwards it to the main release manager, turning the sequence of patches into one big patch (should be possible with mercurial). - The main release manager has to deal with few big patches that *do* apply and are to a reasonable extent tested, rather than with many small patches that are only very little tested (by the referee). Because of passing the partial tests, it would now be easier to find out if the patches introduce problems across different parts (interfaces <-> group theory etc). - If problems arise at that point, then the release manager might say "OK, the problem occurs on Intel Mac in the 'group theory' part after applying the patch delivered by the 'interfaces' lieutenant. So, I delegate the problem and let the 'interface' and 'group theory' lieutenants discuss it together with the 'Intel Mac' guru." Would this simplify release management? Or would it be a regression? After all, the patches produced by the lieutenants would be rather patch bombs. > I know Micheal Abshoff was very helpful when I got started > contributing to Sage, but I'm not sure who I would turn to today if I > was new to this. A lieutenant might be a recognized person to query > about some corner of Sage. I think a new contributor would / should first ask on sage-devel. This is be easier than to first find out who is a "canonical person", and then to contact them off list. > While I have the floor, I'll say I consider frequent releases a real > plus. +1 I must say that the frequent releases of Sage back in 2007 were quite encouraging for me! Best regards, Simon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
