On Mon, 2016-02-22 at 10:04 -0800, Adam Williamson wrote: > > > Also not visible in the mockup: "compose override" packages are *always > > > included in all types of compose*. This is the concept Dennis and I > > > came up with for handling blocker / freeze exception fixes; it's just a > > > more formal version of the current process, really, whereby we mark > > > packages that should be pulled into composes. At present these are only > > > pulled into TCs and RCs, they never appear in the old-style "nightly > > > composes". I believe we should *always* pull them in; it makes the > > > system a good deal simpler. > > > I'm a bit confused here. The override packages were used for TCs and > > RCs, but not for Live nightlies done in Koji. Pungi4 will now do all > > of that as part of a single compose, daily, right? So are you just > > saying those override packages will end up used in all compose > > artifacts produced, and we no longer need to care about the TC+RC vs > > Live nightly difference? In that case that's great. > > Yes, that is what I'm suggesting. If we still have the difference, it > makes things quite messy primarily for constructing an "order" of > composes, because say we do a snapshot the morning after an RC is > blessed; if we haven't done the stable push by then, the snapshot will > inarguably have been built *later* than the RC, but will contain older > packages than it. So what's the order? This is how things work ATM, and > I kinda hate it. And it just makes sense to me that "compose override" > packages should wind up in all the composes, anyhow. There's no reason > to leave them out of snapshots. So Dennis explained that, unfortunately, we can't do this at least for now. When I think about 'composes' I tend to just think about a sort of isolated thing with a bunch of images in it, but of course that's not (all) a "snapshot compose" is. The snapshot composes are what will ultimately be staged out to the public mirrors as the 'official' tree for the release. We cannot put the "compose override" packages into the repositories in those trees, because to do so would be effectively to push them out as stable updates. In theory we could consider putting the "compose override" packages into the images but not the repositories, but we might still think that was a mistake, and in any case, Dennis says, the tools just don't work like that at present. The images are built from the packages in the repos; any "override" packages for a compose *must* be in the repositories for that compose, practically speaking. So for the medium term I think we're stuck with including "override" packages in "candidates" but not "snapshots", and things that do stuff with composes are going to have to understand that distinction. It also means that we're going to have keep doing "snapshots" at the same time as "candidates", as that's how we sync out the stuff that gets pushed stable during freezes to the mirrors. So we're kinda gonna have to treat the "snapshots" and the "candidates" as two separate streams of things, and accept that we can't entirely reliably construct a sequence of them mixed together in some senses (because a "snapshot" built after a "candidate" may have older packages, just as is the case now). There are various ways we can think about dealing with this in the long term, but for now at least we'll just have to live with it. -- 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
