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
> 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 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...
I also wonder if we're thinking about this problem all wrong.
the answer isn't to increase the friction in Rawhide, but instead to
create a regular output stream that people can use to be above
releases? That's more or less how Tumbleweed works, as it's
essentially snapshotted and published from Factory when it "checks
out" via the OpenQA gate. Now, OBS has the nice ability of being able
to have granular control of how publishing actually works. I think the
way Koji's tagging mechanism works may provide a similar capability,
and we could leverage that to produce something like mattdm's
oft-wanted "Fedora Bikeshed".
I think we can have a more stable rawhide without going to a higher
I think there's several parts here when we talk about rawhide
1. Compose stability. I think gating things here and stopping the stuff
that breaks things until it doesn't will be a big win. Thats basically
what we do now, except it takes a bunch of people time to find out nss
broke something, then rdma-core broke something, then something (turns
out to be policycoreutils and setools pulls in 600 new packages) breaks
things. Also sometimes we have images, sometimes we don't.
2. Install stability. The stuff autoqa is testing now. This is often
broken and some human has to sort it out.
3. Day to day use. This is seldom really broken these days. There's
things every once in a while, but overall it's not bad.
Anyhow, I am in favor of the proposal.