On Tue, 2017-02-21 at 03:49 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Feb 20, 2017 at 05:09:55PM -0700, Kevin Fenzi wrote: > > 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... > > Hm, can you explain a bit more how that'd work? Let's say that there > is a mass rebuild for any reason, and some packages are FTBFS, and we > reached the point of "good enough". The side tag is merged back, but > what happens with gating now? Various packages cannot be tested being > their dependants are non-installable... How do we get back to the "clean" > state? An obvious initial option is to only 'gate' on (some definition of) 'core' packages - critpath packages, packages in the base 'module', whatever definition we want to use. We'd only care if *those* packages passed all tests. I actually wasn't that focused on the package-level testing aspect of this proposal. I'm much more interested in the idea of whether Rawhide 'works' in the sense of passing functional tests (i.e., at present, the openQA and Autocloud tests). I'm actively working on setting things up such that a single ResultsDB query for each compose will answer the question of whether it passes all the critical smoke tests, or all the Alpha tests, or all the Beta tests, etc. On that path, of course, only packages involved in the test level we choose to gate on (presumably 'critical' or 'Alpha' at first) need to work. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
