Re: Freezing for 2.18

[David Kastrup]

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

> On 10 mars 2013, at 22:30, David Kastrup <address@hidden> wrote:
>
>> Werner LEMBERG <address@hidden> writes:
>> 
>>>> So, to resume, I agree that a freeze is important.  When the freeze
>>>> kicks in, I'd rather that we say something like "no new big projects
>>>> starting on date X will be part of 2.18" so that developers can plan
>>>> out their next few months accordingly.
>>> 
>>> +1
>> 
>> Actually, "no projects without a serious chance to get finished and
>> debugged until date X" is a more important metric.  Take a look at the
>> "full" \relative proposal: it is a biggy touching several thousands of
>> lines.  But consequences are clear to estimate and shake out, so the
>> decision to do this kind of big thing can be done quite late in the
>> game.  Because the fallout is quite clear and limited.
>> 
>> The starting date is much less important than a realistic view of the
>> wrapup date.
>
> I think it is important for everyone in the community of developers to
> tie off things that they feel to be important before putting out a
> stable release.

"Tie off" as in complete, debug and document started work: sure.  That's
the whole point of going into "stable release" mode.  "Tie off" as in
try to squeeze in as much new stuff as one can while the new stuff from
others has not converged to a releasable state: that's a recipe for
never getting a release done.

> We should feel out where everyone is with their work, life plans and
> when/where a gel in adding things could fit into these things.

Uh, no?  That's not related to going into release mode.  LilyPond is
worked on by a number of individuals and we won't get their lives
synchronized.

> If LilyPond were a piece of commercial software I could understand one
> person imposing a limit, but as it is a team of peers working
> together, I think that everyone should set a limit that makes sense
> for them, announce it, and stick to it.

That's not how a stable release works.  A stable release does not happen
when everybody's time has run out but rather when the state has
stabilized and followup work (documentation, debugging, translations,
taking out rough edges that don't make sense for a stable release) has
caught up with the state of LilyPond.

You see me as "one person imposing a limit" because I brought up the
issue of a stable release here.  But I did not bring up the issue out of
spite and malice but because I realized that the kind of open-ended
changes not leading to any release-related goal but rather to further
open-ended changes that are currently on the table are incompatible with
planning for a stable release in the near future.

I think that a stable release in the near future is something that would
be important, however.

Naturally, it looks to you like I just bring up "stable release" as a
last resort to sabotage your work: the timing is just _too_ suspicious.
But the timing is no coincidence: it does not require an explicit
decision to make a stable release or table it if the state of
development is equally fine for making a stable release at any time.

So I see us at a crossroads here: either we decide we want to have a
stable release in a reasonable point of time in the near future, or we
decide we don't want to plan for a stable release anytime soon.

If we decide we want a stable release at some point in the foreseeable
future, it means to stop adding destabilizing work to master and focus
on stabilizing work instead.

Certainly I am not in the position to make the decision whether or not
we want to focus on a stable release.  That's something we need to
decide by consensus or at least a vote.

But I am in the position to tell people my impression about what will
affect getting a stable release or not.  And I believe that we have
reached a point of time where we can't avoid making a decision about
whether to close the pipelines to master for forward-pointing work or
not, with that decision having a profound effect on the date where we
can expect to make a stable release with good conscience.

I am not in the position to make that decision.  But I am in the
position of pointing out that if we don't make that decision now, the
net effect will be the same as deciding that we don't want a stable
release anytime soon.

> This may push a stable release date back some, but I'd rather there be
> a later stable release that every volunteer developer feels good about
> than an earlier one.

If we allow open-ended work to go into the pipeline as long as we feel
there is open-ended work in the pipeline anyway, we won't get to a
stable release that every volunteer developer feels good about.  Ever.

Yes, the topic was brought up rather abruptly by me, but the reason is
that it is imminent.  It is right now that we have extensive open-ended
work slated to go into master.  Work that is intended to start off new
developments rather than to finish past developments.

So the question for our developers is: do we want to try aiming for a
stable release now or not?  If the decision is that we don't want an
abrupt decision and let in open-ended patches for a few weeks more, it
will mean pushing back the release date for a stable release for several
months.

We can decide either way.  What we can't do is not make a decision: that
will have the same consequences as making a decision.  I may be a pest
for pointing that out but not being a pest would not change it.

-- 
David Kastrup