Re: branching stable/2.22?

[Jonas Hahnfeld]

Am Mittwoch, den 26.08.2020, 00:05 +0200 schrieb Han-Wen Nienhuys:
> On Tue, Aug 25, 2020 at 11:17 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> > > 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.
> 
> Right - but we should refrain from changes that will make the
> backporting process more difficult, so it is still a freeze of sorts.

So what do we do here?
0) Do nothing and continue to break things
1) Prioritize fixes over features
2) Agree on some sort of freeze
3) Branch off stable/2.22 and cherry-pick only fixes

Am Dienstag, den 25.08.2020, 07:51 -0600 schrieb Carl Sorensen:
> Rather than a date, I'd prefer a criterion.
> 
> [...]
> 
> I recommend against creating a stable branch too soon.  In my experience,
> we get much more testing on the unstable branch than on the stable branch.
> People are likely to use the most recent unstable release as a matter of
> course; they are much less likely to go check out the most recent stable
> (but not yet released) branch.

Note that some more unstable releases would follow from the stable
branch, and that's likely what end-users test. Developers will continue
to build master, but any problem seen in the stable branch should
initially also occur in master, right? (unless there's some magical fix
or the issue disappears with some refactoring)

Jonas

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