Fwd: branching stable/2.22?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Fwd: branching stable/2.22?

Jean ABOU SAMRA
Forgot the list, sorry.

Début du message transféré :

> Expéditeur: Jean Abou Samra <[hidden email]>
> Date: 25 août 2020 14:43:21 UTC+2
> Destinataire: Jonas Hahnfeld <[hidden email]>
> Objet: Rép : branching stable/2.22?
>
>
>> Le 25 août 2020 à 12:29, Jonas Hahnfeld <[hidden email]> a écrit :
>>
>> Am Dienstag, den 25.08.2020, 12:06 +0200 schrieb Jean Abou Samra:
>>>> Le 25 août 2020 à 08:30, Jonas Hahnfeld <[hidden email]> 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@.../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
>>>