On Wed, Mar 9, 2016 at 1:47 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > 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 So if "RC-1.8" passes all tests and is a go, how is this renamed? Or is it not renamed? I assume you don't want to do a production compose at this point because then it's a compose that isn't tested, while ostensibly identical the process has any number of non-deterministic aspects to it, right? If so, is there an foreseen consequence of just renaming the filename of the ISOs? Or does the final distributed ISO need to retain the "RC-1.8" add-on? It's sort of a minor point. There are build artifacts now as a single digit since I think Fedora 20, that don't mean anything to the outside world (e.g. for workstation it's 21-5, 22-3, 23-10 for the past three releases). But I don't think they hurt anything really, so if this RC-1.8 add-on is in the distributed ISO, it's only very slightly crusty. But compare this to how Windows eval downloads are named: 9600.17050.WINBLUE_REFRESH.140317-1640_X64FRE_ENTERPRISE_EVAL_EN-US-IR3_CENA_X64FREE_EN-US_DV9.ISO 10586.0.151029-1700.TH2_RELEASE_CLIENTENTERPRISEEVAL_OEMRET_X64FRE_EN-US.ISO So yea, that's pretty terrible. One of those is Windows 8 the other Windows 10. But the world continues to function. -- Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
