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. 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.
Also keep in mind that we already killed the "Alphas" once, the current
"Alpha" is already what used to be the "Beta". Now we want to keep only the
current "Beta" = old "Preview".
I think fewer freezes is not necessarily a bad thing, but are we really
ready for that? I would like to see the gating system in action first to see
whether it can really keep Rawhide in release quality all the time. I am
highly sceptical, given the major changes that go into Rawhide.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
