"m...@mikesolomon.org" <m...@mikesolomon.org> writes: > On 11 mars 2013, at 16:32, "Trevor Daniels" <t.dani...@treda.co.uk> wrote: >> >> I'd also like to propose we adopt the same controls as we did for >> 2.16, if David is willing, since that also worked well. That way >> we'll get a clear plan - what must be fixed, what must be documented, >> what is permitted to go into master, etc. Otherwise we'll simply >> disagree for ever. >> > > I like the idea of freezing right away and releasing after two weeks > of critical-bug-free lily.
Two weeks will not do since we really had no real runner-up time or preparation. > What is difficult for me is setting the freeze down the line without > being able to wrap up work first. Well, while we are in panic mode, lets get more data. Can we agree that "wrap up" means completing work rather than laying the groundwork for further work? We are talking about the state of LilyPond we want to have people working with for 1-2 years, so we don't want half-features and temporary and/or undocumented user interfaces. On my personal wish list are several parser regressions from my own work. I also would like to distinguish the lexer categories of "xxx" and xxx in order to put the symbol list changes into a better light. However, that's a potentially destabilizing change, so it might have to wait. I'd like to get the \relative { ... } -> \relative f { ... } change in which is not even written really. _If_ we decide to change our existing docs/programs to use it by default (and I don't see us making such a decision before three weeks at least), this can only be done sensibly before splitting into branches, or cherry-picking will become a complete nightmare. Now that is a change that people got along without for ten years or more, so adding another year is not really going to let the skies fall. Sigh. And actually, _if_ we consider it desirable, running the brutal conversion rule for 2.18.1 or 2.18.2 would still be feasible in a stable branch (it is quite well-understood and does not change the actual working of the code) and would actually decrease cherry-picking divergence again. I'm just pointing out that synchronizing our wish lists might not go without a few compromises. I also need to do further work on documentation of my own stuff and let the translators catch up with that. As long as we keep divergence of stable and unstable branch to a minimum before stable release, documentation work can reasonably well be done even after the split point. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel