On Thu, 2016-02-25 at 14:57 -0500, Matthew Miller wrote: > On Thu, Feb 25, 2016 at 11:34:57AM -0800, Adam Williamson wrote: > > > > > > > > Maybe I'm Dumb (™), but I'm not following the problem with the > > > "because". *Shouldn't* the override packages be the equivalent of > > > stable updates? > > No. > [...] > > > > In other cases, though, we need to try out a potential fix for an issue > > in a compose, but it might not be good. We might spin up the compose > > and find it broke everything. We definitely *don't* want to be short- > > circuiting Bodhi for those cases. So long as the 'overridden' package > > only shows up in the images, we can fairly safely drop it again if it > > turns out to be bad. If the 'overridden' package also went out to the > > repos, people following Branched would get it as a regular update, and > > we then can't just silently pull it because it leaves them out on a > > limb (we have always resisted doing this very hard in the past; it very > > occasionally happens, but we always hate doing it, we certainly don't > > want to make it a part of common practice). > Well, ugh. Now I understand but am not any happier. :) > > What about having _this_ type of compose be a special outside the > normal system case, and after testing those separately, go back to the > other situation (the short circuit)? Sure, we could do that. We'd need a name for the "special outside the normal system" cases, of course. Something something "compose", maybe? Well, we need to "test" it, so we could call it a "test compose"? waaaaaaitaminute... > Instead of including overrides in "candidates", include them only in... > "override tests", which would only be used to test that the particular > override package was not a terrible idea. > > Then, the _next_ snapshot could be evaluated / validated in full. OK, I think I see what you're driving at, but then you kinda run into the mechanics of the process. Pungi 4 composes are *faster* but they're still not *fast*, they take a couple of hours at minimum. We do not yet have sufficient automated testing for everything we might want to do an "override test" for, so there needs to be a manual step in there somewhere. And we really don't want to be sneak-pushing things into the "stable" repo behind Bodhi's back, the whole design of the system is that anything in the official /development/(release)/ repos went through Bodhi, so we'd still ultimately need to stuff the things we approved via "override tests" through the Bodhi system, with its delays. Plus I'm not sure the mechanics of doing one "override test" per blocker/FE-fixing update quite work...I think the way we can actually implement this "override" mechanism is via Koji tags, but Koji tags aren't free, so we can't auto-create a new one for every blocker/FE- fixing update that shows up, I don't think. We'd have to have one tag that we'd be continually applying to the packages from a single update, doing a compose from, scrubbing, applying to the packages from the *next* blocker/FE-fixing update, rinse and repeat...well, I mean, I guess that could work? So, hum, I guess it's possible. I'm not entirely sure it'd work better than the current system of building candidates with all "override" packages and pushing the overridden packages stable as fast as we can, though. I can see a few advantages and disadvantages...we don't test *interaction* between the overridden updates in this system, and it involves producing and shipping around a *lot* of bits...not sure what Dennis would think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
