On Mon, 20 Feb 2017 18:24:21 -0500 Neal Gompa <ngomp...@gmail.com> wrote:
> On Mon, Feb 20, 2017 at 5:20 PM, Kevin Kofler > <kevin.kof...@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... > I also wonder if we're thinking about this problem all wrong. What if > 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 level here. I think there's several parts here when we talk about rawhide stability: 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. kevin
pgpjCh2v4ZXL_.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
