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. -- 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
