David Kastrup wrote Friday, July 13, 2012 4:27 PM
> Janek Warchoł <[email protected]> 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? 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. 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. c) a more rule-bound system, but with more flexibility. Janek's suggestion is an example. It would be useful to hear views on which of these would be preferred, so we can then concentrate on honing it. Trevor _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
