On Mon, Feb 20, 2017 at 5:20 PM, Kevin Kofler <kevin.kofler@xxxxxxxxx> 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. 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. > 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 for one don't actually want Rawhide to be gated because it makes things much harder in terms of properly developing new features. We're simply not capable of being as good as OpenSUSE in terms of automation to be able to pull off the feats they do. There were major changes to how OpenSUSE did packaging to begin with to be able to pull off what they did, and I simply don't think anyone here is prepared to do even a small bit of that yet. And before someone brings up Factory 2.0 and Modularity (because someone *will*), neither of those solve the problem. Instead they create new ones by completely decoupling package life cycles from the distribution lifecycle (meaning that now it's even harder to introduce distribution-wide changes) and requiring us to shimmy in ways to handle multiple versions for creating weird bundles without being prepared to figure out how to actually keep that sane. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
