"Trevor Daniels" <[email protected]> writes: > David Kastrup wrote Saturday, July 14, 2012 9:30 AM > >> After the first release, the focus of branch maintenance will go from >> _defining/shaping_ a stable release to _maintaining_ it. That >> seriously changes the importance of avoiding new regressions even of >> minor nature, and rules out most "useful" changes that are not >> strictly confined in effect on current behavior and/or bugfixes. >> While the next stable release branch is far from being released, >> well-isolated _additions_ in functionality without effect on >> previously valid files may be subject to consideration. > > I don't understand exactly what you are saying here. I get the > drift, but it would be helpful if you could explain it with reference > to stable branches and master more precisely.
Priorities may change after the first stable release of a major version branch. With respect to this proposal: priorities may change after 2.16.1. >> In any case, after the first release of the stable branch decisions >> on it should become quite more conservative, and it may be that >> handing responsibility off might make for a better fit. It is also >> conceivable that a rule-based approach will work better when the >> release urgency is gone, though I consider it likely that overruling >> automatisms would more likely happen in the opposite direction, >> namely excluding updates that may have passed the formal review >> times, but which the maintainer is not sufficiently confident about. > > So during some period a few weeks prior to the next stable, > selected updates passing review might be marked 'patch-hold' > rather than 'patch-push'? I'd be happy with that. No. Development is not affected unless I specifically ask for it. But it need not really be put into a policy. If it turns out that it is necessary, I expect other developers to listen like I would listen to them in turn if they have a problem affecting their work. Basically the only policy this boils down to is "people committing patches should read lilypond-devel regularly". We might consider special subject lines to make it easier to keep track of important things. Again, this is not specific to the 2.16 release process in itself. >>> - he decides when to have 2.16.0. >>> - he may classify issues as being issue-Critical, but he can >>> still make a 2.16.x release even if there are Critical issues if >>> he chooses to do so. Nobody else can denote issues as being >>> Critical. >> >> Being able to look at a list of Critical issues is useful to make sure >> no oversights happen. So I'd propose that we use the same rules as >> before for marking issues as Critical (in particular, letting a >> regression automatically imply a Critical issue), but that I have the >> leeway of downmarking and/or ignoring them. > > I suggest that you keep any such decision to yourself until > just before the next stable is built, or defer making it until > then. Otherwise interest in fixed such bugs will wane. And in the interest of making a release, I want to have people prioritize on those bugs that will affect the release. That's the main point of having priorities in the first place. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
