"Trevor Daniels" <t.dani...@treda.co.uk> writes: > David Kastrup Monday, March 18, 2013 8:52 AM >> >> It turns out that the pent-up pressure to get forward-looking changes >> into the master branch that have transitory user interfaces or extensive >> changes of internals not exposed to sufficient testing is already too >> high to permit a prerelease phase focused on arriving at stable release >> quality. >> >> So a release process of 2.18 managed by me is off. In the current >> situation, I don't consider it realistic that we will be able to make a >> stable release with sufficient reliability in the next four months at >> least, likely longer. > > It's a pity, but I think you're right. But during that four months or > longer we need to be vigilant to prevent any potentially disruptive > changes entering master. Encouraging or requiring developers to use > branches for anything other than tidying up or bugfixes from now > onwards seems desirable to me.
Well, that's presuming a process between consenting adults, but I am afraid that's something we have to do without: it is obvious that we have severe disagreement of what is and what is not going to lead to a stable release. So we need a process that is going to work out even with severely divergent opinion about what can be made stable in due time and what not. The way to do that is to bind people to their predictions of what can and cannot be achieved in a certain amount of time by agreeing on a timeline in advance and putting in deadlines for certain kinds of changes. I am notoriously bad at organizing such processes, but I am even worse at convincing people that I have a clue what I am talking about. So if we can't arrive at a process where people are prepared to swallow what I (or any other single person) have to say, we have to revert to a process letting everyone eat his own words. That means agreeing on a policy in advance rather than making decisions on the fly, based on the best currently available information. Personally, I very much prefer the latter approach, but since we cannot agree on an interpretation of the currently available information and since the currently active set of developers is too small for arriving at a reasonably representative decision for dictatorship (or whatever one would want to call placing the responsibility for making some calls into a single hand), it's the best we can do. So probably after my climbing trip I'll prepare something akin to Graham's GOP proposals that will spell out time frames that most developers will feel comfortable agreeing with. Now. It's not my style of working, but it is obvious that my style of working does not work in this case. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
