Re: Freezing for 2.18

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup <address@hidden> wrote:
>> 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.
>
> Uh, i see a dangerous situation here.
> David, i may be wrong, but i'm afraid it looks like you are assuming
> that Mike thinks you are sabotaging his work.  I'm pretty sure that
> Mike doesn't think you're sabotaging his work.
> Please - for the sake of reducing misunderstandings - don't
> guess/assume what others think about your decisions/proposals.
> In other words: it seems to me that you perceive a conflict/resentment
> where there is none.
>
>> 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.
>
> Agreed.  Nevertheless, stabilizing master doesn't have to mean pausing
> "unstable" work.  I think it can be done in a branch.

That's exactly what the disagreement is about.  Quoting from
<URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/53128>:

    > What's it good for with regard to the current feature set?  It
    > does not matter how good it is going to be for future tasks for
    > the question of whether one wants to see it in 2.18.  What ends up
    > in 2.18 is something that people can expect to depend on in 2.20
    > as well.  If it is preparation for future work, it is unlikely
    > that it will stay identical once the future work is getting
    > tackled.

    I _completely_ agree with you that it is high time for 2.18.  I also
    think it is important to not start big projects after a freeze date
    is announced.

    Given that the translate_axis patch is fresh on my and other's minds
    (i.e. the reviewers on Rietveld, the most recent being Keith), I'd
    rather push it in the next couple weeks and then fix any bugs in the
    next 4-6 weeks rather than waiting.  Not only will it save time for
    me and reviewers, but it will also help me start doing the brainwork
    for the next big thing.  Perfect timing, for me, would be like what
    we did for 2.16 in Waltorp.  If I know when a freeze is arriving, I
    can coordinate my work so that, again, I can make my next large
    change ready right after the stable release comes out.

-- 
David Kastrup