> 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. Could we include the override repo as another directory in the compose tree, and the image building tools would automatically use it if present? -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
