On Thursday, February 25, 2016 02:57:04 PM 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. :)
In a world where we only push out bits that have passed openqa we should detect the types of breakages that we wouldn't want to ship. It really boils down to if we put the compose on /pub/fedora or not. Dennis > 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)? > > 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.
signature.asc
Description: This is a digitally signed message part.
-- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
