Re: branching stable/2.22?

[Jean Abou Samra]

> Le 25 août 2020 à 08:30, Jonas Hahnfeld <hahnjo@hahnjo.de> a écrit :
> 
> Am Montag, den 24.08.2020, 22:10 +0200 schrieb Jean Abou Samra:
>>>>>> As sort of a shot in the dark, how about planning the 2.22 release for 
>>>>>> May 2021, for example?
>>>>> 
>>>>> Do you mean branching stable/2.22 or releasing 2.22.0 in May 2021? In
>>>>> my understanding, the past process includes the release of beta
>>>>> versions from the branch. That makes it close to impossible to predict
>>>>> the final date of the stable version, and that's not the purpose of
>>>>> this thread.
>>>> 
>>>> I mean releasing 2.22.0 in May 2021. This is not about predictions, but 
>>>> objectives. I think that instead of planning each small step on the fly 
>>>> with no idea how the future looks like, we should settle an expected date 
>>>> for the release and plan backwards accordingly. Sure, there could be 
>>>> critical bugs that delay the actual release, but setting the expectation 
>>>> enables more resources to focus on the release by the time it is due to 
>>>> happen. In my opinion, this is the way we can avoid things like the 2.14 
>>>> release that is documented in the CG.
>>>> 
>>>> So, an expected release in May 2021 would mean branching release/2.20 
>>>> around January (?) and beta releases at a monthly cadence until the 
>>>> release is out.
>>>> 
>>>> I'm curious about what others think of that. In fact it looks like you 
>>>> already proposed something along these lines:
>>>> https://www.mail-archive.com/lilypond-devel@gnu.org/msg72997.html
>>> 
>>> And it didn't get much support. Which is why I don't see what's
>>> different today. Asking what it would take to branch is really the only
>>> sensible thing I think we could possibly agree on.
>> 
>> As I see it, you're asking something nobody, apparently, can give you. We 
>> need to create the process instead of finding it out: what do you think it 
>> should take to branch?
> 
> For me, creating the branch is nothing more than saying "feature
> development is over and the current set is worth making stable". Which
> I'm arguing is already there with Python 3 and the possibility to use
> Guile 2. See my very initial message.

At the same time, you're saying that branching is not going to happen next 
week. Please elaborate on your mind: when should that happen?

> On the administrative side, I think
> * there should be another reformatting for all C++ and Scheme
> * docs should be updated, including authors.itexi
> Everything else can and should be picked as needed.
> 
>> Branching means collectively commiting to creating a stable release a 
>> handful of months later, otherwise we get to the situation that David 
>> described in his last reply: the stable branch comes so far from master that 
>> features need to be ported to it; clearly, that's not a desirable workflow.
> 
> I don't understand why you would want to backport features? IMO that's
> got nothing to do with how far the stable branch diverges.

I was talking about what happened in 2.20:

> It's worth stressing that the 2.20 branch persisted much longer before
> the 2.20 release than planned.  So there were also some feature
> cherry-picks in order to avoid the situation that the 2.20 release would
> be "outdated from the start" with regard to some "must-have" features
> that would be expected to be common in suggested code on the mailing
> lists.


Now, you might say that if we do more frequent releases, the problem will 
disappear. This means, however, that we're planning to make releases more 
often, which is a decision that extends far beyond simply planning the 
branching time.


>> Whatever the option, we will need people to manage the release (yes, I could 
>> possibly help next summer ... though I'm afraid I'd be NOT_SMART).
> 
> If it's just missing people to do the work, I obviously volunteer and
> am willing to cherry-pick fixes from master as needed.

Nice!

>> So, I think the question is essentially wether we try to plan the release 
>> now or just wait for the essential features we'd like in it to be 
>> implemented, e.g., full Guile 2 support. Personally, I think it's better to 
>> plan it so hopefully developers will naturally organize their respective 
>> works accordingly. In this perspective, if full Guile 2 support is not 
>> implemented by the deadline, it just waits for another release. But that's 
>> just my opinion.
> 
> From my experience in the LLVM project, there is no such thing as
> "naturally stabilizing code". Either you create a branch and pick fixes
> or you have a strict policy that allows only fixes to master before
> branching. That's basically the model GCC is using, and I don't think
> it fits the community.

I was not meaning that the code base would naturally stabilize but instead that 
developers would be able to plan what features they can implement in the time 
that runs from now to branching. Predictability makes people happy.

We're having, in fact, similar views. You say that we need to stabilize the 
code base through branching, which I  entirely agree with -- except that right 
now is not the right time. What I'm trying to convey here is that postponing 
decisions on the ground of them being controversial is damaging to team 
members' morale.

To me, for the above-mentioned reasons, settling a date for branching 2.22 
amounts to scheduling the 2.22 release, which is why I think we should 
explicitely discuss that schedule, instead of making short-term decisions that 
only have consensus because the consequences weren't discussed, with no longer 
term perspectives. The contrary would let the community split into small groups 
of like-minded persons that avoid each other because don't want to go the 
trouble of convincing each other. Given that you're ready to endorse the 
release manager role and responsibility, I no longer see any blocker to 
scheduling 2.20, except getting agreement about the schedule.

So we better start arguing about the schedule.

Cheers,
Jean