Re: 2.21.0 release plans and considerations

[Jonas Hahnfeld]

Am Montag, den 02.03.2020, 19:38 +0100 schrieb 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?

Sure, the solution is to apply #5799. Turns out the solution is not
only for x86_64-w64-mingw32 but also for 32 bit mingw that GUB uses. So
I'm arguing that it should go in before 2.21.0 is cut.

Jonas

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