Re: Freezing for 2.18

[David Kastrup]

"address@hidden" <address@hidden> writes:

> On 11 mars 2013, at 16:32, "Trevor Daniels" <address@hidden> 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