On Wed, Mar 9, 2016 at 11:16 AM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > 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 In this format option, MILESTONE-N.R would be MILESTONE= alpha, beta, RC N = arbitrary integer R = arbitrary integer Can N and R be 0? Or must it be 1-9? > 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. To reduce granularity, lock down either N or R. But if locked down, I suggest a value of 0 rather than 1 to indicate nullification. > 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). At least from the test side, I'm not thinking there was ever a meaningful distinction between TC and RC for alpha and beta. For final, I vaguely think TCs and RCs did change behavior in some ways, maybe it was disabling u-t by default? Or maybe some installer labeling or warning goes away? If you want to keep some granularity to distinguish between TC/RC you could use N=0 to indicate "TC" and N=1 to indicate "RC". :-P TC's alpha-0.1 alpha-0.2 alpha-0.3 alpha-0.4 beta-0.1 beta-0.2 beta-0.3 RC-0.1 RC-0.2 legit RC's alpha-1.1 alpha-1.2 alpha-1.3 alpha-1.4 beta-1.1 beta-1.2 beta-1.3 RC-1.1 RC-1.2 Further, if there is no meaningful distinction between TC/RC during alpha and beta, then those would always be N=1. You'd only nullify "RC" with a trailing 0 for the final TC's. -- Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
