[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: branching stable/2.22?

From: David Kastrup
Subject: Re: branching stable/2.22?
Date: Fri, 11 Sep 2020 16:22:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]