Re: branching stable/2.22?

[Jonas Hahnfeld]

Am Dienstag, den 25.08.2020, 22:56 +0200 schrieb 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?

If followed strictly, it means no feature commits in master during the
freeze which leaves two options: Either features build up in private
and it'll be serious work to integrate them after the freeze ends, or
they're not developed at all which is also bad.

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

Right, that is the trade-off. So really no easy solution to the
problem.

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

My feeling is that we should prioritize on bug fixes, but not actively
block the development of features.

Jonas

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

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