On Mon, Feb 20, 2017 at 05:09:55PM -0700, Kevin Fenzi wrote:
On Mon, 20 Feb 2017 18:24:21 -0500
Neal Gompa <ngompa13(a)gmail.com> wrote:
> On Mon, Feb 20, 2017 at 5:20 PM, Kevin Kofler
> <kevin.kofler(a)chello.at> wrote:
> > Dennis Gilmore wrote:
> >> I do not get what you mean by your statement, it is extremely vague
> >> with no detail. can you please expand on it in the context of the
> >> change? and the changes it will bring to the entire workflow of
> >> rawhide?
> > Rawhide is just nowhere near working, half the packages have broken
> > dependencies due to not building with the latest GCC.
Thats a bit over dramatic don't you think?
968 currently on the FTBFS list, and even there many of those don't
have broken deps because the previous build still works.
> If you really
> > implement your gating idea to "fix" that, this means the mass
> > rebuild (and the new GCC!) could NOT be tagged until ALL the broken
> > dependencies are fixed. That may take months. Or you freeze GCC
> > (and similar packages) on a fixed version forever and never upgrade
> > it again (kinda like in the old RHL 7.x days where that 2.96
> > snapshot was kept even when 3.2 was current). If that (withholding
> > new compilers for months until all packages work with them) is not
> > the plan, then the gating will not do any good, because that is
> > where the breakage comes from, not updates of leaf packages.
Yeah, the mass rebuild case will need to be excepted once it's "good
enough" or have some other way of landing...
Hm, can you explain a bit more how that'd work? Let's say that there
is a mass rebuild for any reason, and some packages are FTBFS, and we
reached the point of "good enough". The side tag is merged back, but
what happens with gating now? Various packages cannot be tested being
their dependants are non-installable... How do we get back to the "clean"