Re: 2.21.0 release plans and considerations

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup:
>> > 
>> > 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.
>> 
>> Understood. In that case I'll work to prepare GUB for 2.21.0, at least
>> something I can likely help with.
>
> See https://github.com/gperciva/gub/pull/71. Incidentally this only
> works for mingw after #5799 is applied (or at least the first commit).
> So while it has the potential to break, it actually fixes things 😉
>
> FTR: I guess the offending commit is b51e6224ab ("Issue 5776/1: Drop
> check for std::vector::data()") where I innocently removed an inclusion
> of config.hh. I'd argue that it has been broken before, this was only
> uncovered by removing the include.

Frankly, I am not overly interested in arguing what level of brokenness
is really "somebody else's problem"™.  Since you are the person who
currently appears to have the best overview, could you design a fix you
consider less broken?

I am currently trying to get the translation infrastructure moving over
to unstable so that translators can, at their choice, do some
after-the-fact polishing of 2.20.0 (then due to appear in 2.20.1 at some
point of time) or dive into 2.21.  The reason is that we want to get
2.21.0 out the door as fast as possible and return back to business.  Of
which there does not seem to be a dearth...

Thanks!

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".