[Top][All Lists]

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

Re: 2.21.0 release plans and considerations

From: David Kastrup
Subject: Re: 2.21.0 release plans and considerations
Date: Sun, 01 Mar 2020 15:39:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Jonas Hahnfeld <address@hidden> writes:

> could you maybe flag those patches under review that you think should
> not go in? I guess everybody considers the own changes to be
> "important", so I'm not 100% sure which patches fall under that
> category.

"Important" is absolutely no criterion.  It has been easy to forget
recently, but when our "unstable" releases are not made from the stable
branch as stable prereleases, the update rate is about every 2 weeks.

Whoever installs an unstable release is warned that they should be
prepared for frequent updates because unstable releases are not expected
to get everything right.

So the lasting importance of 2.21.0 is _not_ as a release in its own
right but as a base point for figuring out "when did this or that stop
working?".  While Git bisection is nice to have, it is also slow, and
sometimes it just stops working because of updates in the compilers that
preclude compiling on newer systems.

So our official releases are the _main_ way to figure out where some bad
behavior stopped.

> That's maybe also due to lack of knowledge what has caused problems in
> the past.
> For example, I'd very much like #5799 to be part of 2.21.0 to be able
> to cross-compile to x86_64-w64-mingw32 and show-case a replacement for
> GUB. However I acknowledge that the changes have at least the
> potential to break the current process using GUB.

That sounds like an _excellent_ reason to very much _not_ want #5799 as
part of 2.21.0.  Again, the importance of 2.21.0 is utterly different
than that of 2.20.0.  For 2.20.0, there may be strong reasons to want
some change _in_ because that's what is going to be there a long time.
For 2.21.0, there should only be strong reasons to want some change
_out_ because the next release is just around the corner while the
previous release from the unstable branch (2.19.65 or something?) has
been eternities away.  It would have been prohibitive to block
development on master while stable was maturing.

But fortunately, we are now at the point where 2.20 _and_ 2.21 are going
to be a thing rather soon.  Assuming that things like the Python3
migration don't cause more of a standstill for 2.21.0 than we imagine,
but then one can still decide to stop being disciplined until things are
fixed enough to get 2.21.0 done.

David Kastrup

reply via email to

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