Re: branching stable/2.22?

[Han-Wen Nienhuys]

On Tue, Aug 25, 2020 at 8:31 AM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> 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.

I am happy to help with fixing bugs for the stable release.

> 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 agree that we have to do something, either branching and
cherry-picking, or holding off on work that destabilizes the
situation.

I don't understand why you think the GCC model doesn't fit, though?

I think the branching model has the problem that someone has to do the
work of backporting, which is probably less fun to do. If in parallel
cowboys like me keep submitting experimental things to master,
backporting the fixes is made all the more difficult.

I think the stabilization effort could be a joint effort by the entire
dev team, by agreeing with the team to hold off on new features and
invasive changes for a period of time (say, 1 to 2 months).

BTW- aside from GUILE 2 and Python 3 support, I think users will also
be happy with the speedups that I've been working on in this cycle.

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen