Re: branching stable/2.22?

[Jonas Hahnfeld]

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.
(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, January 2021 being a shot in the dark?

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

signature.asc
Description: This is a digitally signed message part