Re: branching stable/2.22?

[David Kastrup]

Jonas Hahnfeld <hahnjo@hahnjo.de> writes:

> Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
>> > Here is my proposal for how to go ahead:
>> > 
>> > * we build a 2.21.6 from master, and announce it widely as a 2.22
>> > pre-release version.
>> 
>> Adding Phil. I did a full test build of current master yesterday and it
>> worked fine with https://github.com/gperciva/gub/pull/80 in place.
>> With respect to wording, every 2.21.x is some kind of pre-release for
>> 2.22. If this proposal gets consensus, I'd emphasize that feature
>> development is over, but I'll leave that to native speakers 😉
>> 
>> > * we institute a X week freeze; during the freeze, we only merge
>> >   - fixes for regressions
>> >   - updates to the documentation
>> >   - cleanups with no functional changes, with little risk (ie. refrain
>> > from build system changes, for example).
>> > * after the X week freeze, if we still have open regressions, we tack
>> > on another few weeks of freeze to fix them.
>> > * if there are no regressions left, we branch stable/2.22, and release
>> > a new pre-release.
>> > 
>> > X could be up for discussion, but 3 or 4 weeks seems long enough to
>> > gather some feedback, but short enough that experimental/feature work
>> > should not be affected.
>> > 
>> > The objective of the freeze is to focus developer energy on fixing
>> > regressions rather than causing new regressions.
>> 
>> Sounds good to me.
>
> To arrive at a decision, what do others think about this? Having a
> large silent mass is not really helpful for this kind of discussion (as
> it wasn't for the switch to GitLab).

Frankly I don't see the point in repeating points I already made and
call that "discussion".

I don't see that in the current stage of upheaval of both internals and
build system and infrastructure, there is a point in freezing off some
half-baked intermediate state that hasn't seen significant exposure to
extensive testing.

-- 
David Kastrup