Re: The Freeze

[Janek Warchoł]

2013/7/1 David Kastrup <address@hidden>:
> 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.

My impression was that it slowed /too/ much.  But it's certainly
possible that i'm wrong.

>> 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.

a totally side note: no, it's not obvious for me.  I had no idea about
us having this problem - please don't overestimate my capabilities ;-)

> 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.

This looks like important piece of architecture/design information.
Should i put it into CG, or will you do this, or is it already therre?

> 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.

???????
Do you refer to what i wrote privately in "Path to LilyPond 2.18"
thread, at the beginnig of June?  If so, i don't understand how you
came to this conclusion.  Usually i do understand what you mean, but
not now.

> 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.

I think you're misinterpreting my intentions.  My primary desire isn't
"i want my patches reviewed".  Rather, my primary desire is "I want to
do something good for LilyPond, efficiently".
I've noticed that i'm efficient at doing medium scale reorganizations
and extending (http://code.google.com/p/lilypond/issues/detail?id=3239
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/dev/janek-alignment
- i think it's a well-done job, correct me if i'm wrong).  But to do
this i need reviews.
What i want is to maximize the value i can give to LilyPond project.

> At any rate, I don't see a reasonable alternative to tieing together a
> reasonably coherent and workable version for our end users _now_.

Ok, i'm not going to oppose doing this.

> 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.

Hmm.  I didn't think that it could be the long delay in releasing 2.16
that caused developers to become less active.  You may be right, and
releasing 2.18 may be more important than i thought.  Consider me
partially convinced.

best wishes,
Janek