Re: The Freeze

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> it's been a while since we announced the freeze aimed at releasing
> 2.18.  I'm not sure if it's working properly, though: it seems that
> the development process lost a lot of momentum.

Uh, why wouldn't the development process lose momentum in a freeze?
That's pretty much the purpose.

> (As for the remaning critical bugs, i feel quite incompetent in these
> areas...)
>
> Summer months were usually the most active ones for LilyPond (at least
> that's what statistics say), so i think that it would be good to end
> the freeze - even if that means saying goodbye to 2.18 this year. (but
> that's just my personal opinion.)

There has been quite a lot of work on getting regressions under wrap,
much of that by Keith.  Documentation is proofread and improved.

> At any rate, i have holidays now and i want to "spend them" mostly on
> LilyPond: i want to bring at least some of the gsoc stuff to a
> finished state.  Also, as i've written in another email, my cousin is
> working on LilyPond as his University internship and i'm helping him;
> we hope to have some serious work done during the summer.
>
> It will help me *immensely* [1] if i'll be getting reviews on my
> patches, and reviews on new features/architecture changes tend to
> appear when there is no freeze - that's why it would suit me to end
> it.  But please don't feel obliged or pressured to do this.  Freeze or
> no freeze, i'm going to do some coding and put patches for review.

If we say "goodbye to 2.18 this year", this essentially means saying
goodbye to stable releases forever.  At the current point of time we are
trying to play catchup with lots of regressions introduced in the 2.17
cycle.  Some of that is due to shoddy work that did not receive the
right amount of scrutiny in reviews or otherwise before getting
committed.

Some of it is due to design decisions that result in whack-a-regression
games.  I think it is pretty obvious by now that the "every grob should
be able to look at its neighbors" approach does not scale.  Apart from
the obvious computational complexity consideration of scaling, we don't
have anything in place that would actually deal with the growing
dependency mesh programmatically, so we get "circular evaluation"
problems that grow exponentially with each neighbor a grob looks at.

There is a reason that we have collecting grobs like TieColumn and
NoteColumn that have their own resolution and arrangement algorithms.

At any rate, I had already proposed releasing 2.17.95 in order to make
clear that we want to have a stable release shortly and get to a final
effort.  People including a certain Janek Warchoł were against that kind
of signal without me being overly convinced.

Now you propose blowing off the stable release off altogether since you
feel that kind of signal will give you more reviews.  After the claims
that no signal is needed for getting to a stable release, I consider
this approach for gathering more interest in unstable developments
distasteful.

At any rate, I don't see a reasonable alternative to tieing together a
reasonably coherent and workable version for our end users _now_.  The
kind of "let stable releases be screwed" attitude that ended up delaying
the release of 2.16 for longer than a year after its first release
candidate was announced has cost us dearly, alienating users as well as
making developers quit in frustration.  You consider it fine to repeat
that.  I don't.

-- 
David Kastrup