Hi folks! So we're now frozen for Alpha and we have an anaconda build with blocker fixes in updates-testing...I guess this means it's a good time to decide what to do about milestone builds with Pungi 4. :) I'm assuming here that we're going to use more or less the same "TCs and RCs" approach for F24 and just try to adapt it to Pungi 4. It seems a bit late to make radical changes to the process itself at this point. I have a couple of ideas. I'm gonna recap, briefly, what (as I understand it) Pungi 4 expects us to do for milestone builds: We're expected to run 'pungi-koji --label foo', where 'foo' is a compose 'label' in Pungi's expected format. AIUI, this is the format Pungi expects for a compose 'label': MILESTONE-N.R where MILESTONE is the milestone (there is a list of valid milestones; for our purposes we're likely to use Alpha, Beta and RC), 'N' is the release number, and 'R' is a respin number. Both N and R have to be integers (though they can have multiple digits; Alpha-11.23 would be a valid label). Fedora does not do numbered milestone releases; we just have Alpha, Beta and Final. RHEL does, which is why the label format has 'N'. In the RHEL process, as I understand it, they build "Alpha-1.1", then if it passes whatever requirements are needed for an "Alpha 1" release, they ship it as Alpha 1; otherwise they build "Alpha-1.2" and ship that if it passes, etc etc. The "respin" value is considered "private", and respins are used for about the same purpose we use TCs/RCs. It *is* possible to do a 'production' compose with no label, I believe, by calling 'pungi-koji --no-label'. It would *also* be technically possible to add new label formats to Pungi. So we do have three options at the high level: a. Work with Pungi's currently-expected label format b. Patch Pungi to support a more Fedora-y label format c. Don't apply a label to our TC/RC composes at all I would suggest that a is the best practical choice, though, because we know this is how Pungi is kind of expected to be used. b is likely to take time to work out any kinks, and c seems unnecessarily extreme; we should be able to come up with a usable label format that gives us valuable information. So assuming we go with 1) at the high level, I see a few possibilities for how to do this. == 1. Just use one value == In this design, we'd set one of the numbers to 1 (or I guess 0) for every single Fedora compose, and just increment the other. I was thinking we'd lock down the release number (N) and just increment the respin (R) - so we'd do Alpha-1.1 then Alpha-1.2 then Alpha-1.3 and so on. This seems like it'd work fine for Alpha and Beta but be a little odd for Final. 'Final' is not a valid milestone for Pungi 4, it expects you to use 'RC' as a milestone and build 'RC1.1', 'RC1.2', 'RC1.3', 'RC2.1' etc etc. It'd be a bit odd for us to have 'RC1.1' as 'Final TC1', 'RC1.2' as 'Final TC2', 'RC1.3' as 'Final RC1', etc. So we could instead lock down R and only increment N, so we'd do 'RC 1.1', 'RC 2.1', 'RC 3.1' and so on. The build called 'RC 1.1' would likely not really be a "real" RC (in the sense it'd happen while we were not frozen and not have all blocker bugs fixed), but that's not horrible. I suppose we could relatively easily add 'Final' to Pungi's list of milestones too, if we wanted (or 'TC', come to that). The other possible problem with this is it makes it hard to keep the TC/RC distinction. We could build the composes as 'Alpha 1.1', 'Alpha 2.1', 'Alpha 3.1' and put 'Alpha 1.1' in a directory called 'Alpha_TC1', 'Alpha 2.1' in 'Alpha_TC2', and 'Alpha 3.1' in 'Alpha_RC1' if we wanted, but you couldn't easily map from one name to the other, because there's no way to know the cutoff where we switched over - if you only know you're dealing with 'Alpha 2.1', you can't tell if that's 'Alpha TC2' or 'Alpha RC1'. The question then is, do we actually need the TC/RC distinction for anything? I'm not sure we really do. But if we want to keep it, we could try... == 2. N indicates TC/RC, R indicates number == In this scheme, we'd build e.g. 'Alpha 1.1' (Alpha TC1), 'Alpha 1.2' (Alpha TC2), 'Alpha 2.1' (Alpha RC1), 'Alpha 2.2' (Alpha RC2). This seems like the closest possible way to map to our current system. Again it's a bit weird at Final because there is no 'Final' milestone, only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be 'RC1', which is kinda strange; again we could add a 'Final' milestone to Pungi, I guess. I'm just not sure, as per 1), if we really *need* to maintain the TC/RC distinction at least in terms of how the composes are labelled and distributed. == 3. Some kinda hybrid == We could combine things, so we do 1.n for Alpha and Beta, then n.1 for RC (so we have Alpha 1.1, Alpha 1.2, Alpha 1.3, Alpha 1.4, Beta 1.1, Beta 1.2, Beta 1.3, RC1.1, RC2.1, RC3.1 etc). This is viable, but I'm not really sure it's necessary. It seems simpler to pick some variant of 1 or 2. There's a final question, which is whether we adopt the Pungi 'label' naming format for all purposes - so we put the composes in directories named Alpha-1.1, Alpha-1.2, Alpha-1.3 and so on, and we call the validation events something like 'Test Results:Fedora 24 Alpha 1.1' rather than 'Test Results:Fedora 24 Alpha TC1'. It's probably simpler to just go with the label names, but if people are really used to the TC/RC names we can stick with them if we choose option 2 or 3. It would be difficult to keep them with option 1. I'm not sure what Dennis' thoughts are on this. As a final note, just so people are aware: all Pungi 4 composes have compose IDs, so a 'production' compose with a label has *both* a compose ID *and* a label. The compose ID for a production compose is, I believe, something like 'Fedora-24-20160309.0' - it looks quite a lot like a nightly compose ID, but without the '.n.' that denotes nightly. There is no letter identifier for 'production' composes, they just omit it entirely. This is mostly a thing for me to deal with in tooling, though... -- Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
