Re: branching stable/2.22?

[Jonas Hahnfeld]

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.

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.

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

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

Jonas

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