Fwd: branching stable/2.22?

[Jean Abou Samra]

Forgot the list, sorry.

Début du message transféré :

> Expéditeur: Jean Abou Samra <jean@abou-samra.fr>
> Date: 25 août 2020 14:43:21 UTC+2
> Destinataire: Jonas Hahnfeld <hahnjo@hahnjo.de>
> Objet: Rép : branching stable/2.22?
> 
> 
>> Le 25 août 2020 à 12:29, Jonas Hahnfeld <hahnjo@hahnjo.de> a écrit :
>> 
>> Am Dienstag, den 25.08.2020, 12:06 +0200 schrieb 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?
>> 
>> After below points have happened and after gathering agreement that
>> there are no open blockers to branching. IMO that would be something
>> fundamentally broken which can be expected to hit every user. AFAICT
>> that's not the case. Other problems can be addressed by picking fixes
>> into the branch.
> 
> That can happen in a week, can't it?
> 
> I can't follow your mind anymore. You previously agreed with David that the 
> code base was in too much of a destabilized state for branching soon. We're 
> talking about bugs that we don't yet know but could pop up in the months to 
> come given this state.
> 
>> (It probably makes sense to branch right after making some future
>> unstable release, which implies that GUB is mostly happy, but that's
>> some minor detail I would say.)
>> 
>>>> 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.
>>> 
>>> [...]
>>> 
>>> 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.
>> 
>> So what objective function would you use to set an agreeable date? Just
>> time,
> 
> Yes, that is basically the idea. I think schedules help people work together 
> even if later deviated from.
> 
>> January 2021 being a shot in the dark?
> 
> Do speak up about what you would consider a more reasonable time.
> 
> Also, I value the actual date less than I value agreement on the date.
> 
> Best regards.
> Jean
> 
> 
>>> 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
>>>