"Trevor Daniels" <t.dani...@treda.co.uk> writes: > David Kastrup wrote Friday, July 13, 2012 4:27 PM > > >> Janek Warchoł <janek.lilyp...@gmail.com> writes: >> >>> This is important, too, because Graham won't always be the Project >>> Manager. It's also not guaranteed that there'll always be an >>> experienced developer with sufficient time to handle release tasks. >> >> I just don't buy the "experienced developer" thing. Currently we let >> our stable release process effectively be governed by randomness: we are >> waiting for a large gap in the Poisson process detecting regressions. >> If we instead delegated that decision to a moron without a clue, he >> would likely try to figure out from others what he is supposed to do. >> Which would be a large step forward in contrast to what we do now. > > Three of us at least seem to take the view that rigid rules > governing the making of a stable release has not worked > well. So we are looking to replace those rules with a process > that involves intelligent decision-making. What choices do > we have?
Oh, some rules certainly do make sense. The trick is to apply them rather than follow them. It makes sense to have a cooldown period of at least two weeks to check whether any new tricks blow up around one's ears. But then one needs to figure out how to deal with them. Rewind, restart countdown, for things that happened years ago without people noticing? That does not make sense. For catastrophes occuring just before, more so. Do we need to restart countdown? Sometimes a revert may be safe enough. And so on. The rules are supposed to help us, not block us. We need to be able to deal _appropriately_ with them, and there is no rule set that would fit every situation when followed blindly. > a) a release-meister with responsibility to take all decisions. > That's what Han-Wen used to do, I believe. It worked > quite well, although Graham will have more of an inside view > than I. Would need to be someone with a similarly wide > overview. > > b) a release manager who takes final decisions, but only > after due consultation. That's the same, essentially. It is still the same amount of responsibility. We can do musical chairs if we find nobody willing to do this all the time. > Bugs would be classified as release- blocking or not, and blocks would > also be imposed while a major development was still being matured. A > release could be made any time there were no blocks, or maybe after > some set period free of blocks. Involves lots of consultation - maybe > a good thing. Basically the release manager will say "in the current situation, I think I'll tag the release on xxxx-xx-xx if we got bugs/regressions yyyy and zzzz fixed in a manner we can agree to be reasonably workable until vvvv-vv-vv." And if he doesn't, too bad. > c) a more rule-bound system, but with more flexibility. > Janek's suggestion is an example. Rules are nice. But I have come to distrust "rule-bound". If someone does a job in the manner the others don't like, let the next step up and do it better. > It would be useful to hear views on which of these would > be preferred, so we can then concentrate on honing it. Well, I am obviously currently in a mood to dismiss the parliament and declare military rule, so I probably should take a break of a few days in this discussion. I don't find myself able to contribute in a manner that is actually constructive and where I find myself receptive to other views. Not that this would be a strong suit of mine, anyway. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
