Jonas Hahnfeld <hah...@hahnjo.de> 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".
