On Tue, 2016-02-23 at 19:09 -0800, Adam Williamson wrote:
On Sat, 2016-02-20 at 15:33 -0800, Adam Williamson wrote:
Hi folks!
So I've been working lately on revamping the release validation process for Pungi 4 composes. I've made quite a bit of progress, but I'm now kind of stuck, because we don't know how the full release cycle is actually going to work with Pungi 4 composes. There are some questions that haven't been answered:
- What will the compose IDs be for anything other than Rawhide snapshots?
- When do we compose what kinds of composes?
- What information do we need about the composes and where?
I've asked if there are any plans about this a few times, and the answer has always been "not yet". So I figured instead of sitting around waiting, I'd think the issues through and come up with a proposal!
So I did a bit of digging around in pungi4 / productmd code today. Unfortunately it didn't really make me that happy :/
Simply put, productmd does all the things I've been thinking are a bad idea (in terms of encapsulating all sorts of specific properties of a particular compose process) and this is broadly tied into pungi4.
I'm looking at stuff like this:
https://pagure.io/pungi/blob/master/f/bin/pungi-koji
that's the executable releng actually has to call to produce a compose. Note that it doesn't let you simply say: hey, I want a compose with ID foo. Oh, no. It requires you to specify '--nightly' to produce a "nightly" compose, or '--test' to produce a "test" compose. If you leave both of those out, you get a "production" compose, and are required to specify a "label" - but you can't just pick your label, because it calls:
productmd.composeinfo.verify_label(opts.label)
Hmm, on second thoughts, I need to take this back a little. I got kinda lost in the code and have only just realized that the "label" and the "compose ID" are separate concepts. At least just looking at the code, I think it works like this. All "compose IDs" follow a similar format:
Fedora-RELEASE-DATE(.TYPE).RESPIN
for nightly composes type is 'n', for test composes it's 't', for production composes there is no type - the part in braces is omitted. So we might have:
Fedora-24-20160224.t.0 (a test compose) Fedora-24-20160224.n.0 (a nightly compose) Fedora-24-20160224.0 (a "production" compose)
which...I mean, it still encodes a bit more information than I'd love, but it's not awful. And it does map quite well to the current Fedora process, where as we've established, we *do* need to treat 'nightly' and 'production' composes - or what I called "SNAPSHOT" and "CANDIDATE" composes - as separate things, at least for now.
the label is a *separate* property which only "production" composes have. Test and nightly composes do not have one. That's the thing that looks something like:
Alpha-1.1
so this actually is kinda implementing the idea that you can decide what a compose "is" in terms of the release process separately from assigning an ID to it...only you're required to do it *at the time you build the compose*. I think it'd be good to separate the "apply a label" step from the "create the compose" step, but conceptually it's not terrible. It shouldn't be incredibly difficult to make productmd support a more Fedora-y label format, if we want to do that.