Re: F27 System Wide Change: No More Alphas

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 20 Feb 2017 18:24:21 -0500
Neal Gompa <ngompa13@xxxxxxxxx> wrote:

> 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. 

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

Attachment: pgpgvmF5bSrBE.pgp
Description: OpenPGP digital signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux