On Wed, 2016-03-09 at 13:47 -0700, Chris Murphy wrote: > 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? At least according to the regex that tests their validity, they can be 0, yes. > At least from the test side, I'm not thinking there was ever a > meaningful distinction between TC and RC for alpha and beta. Right, this is my take on it too. The *definition* is clear enough: it's only an RC if it happens after the freeze *and* there are no outstanding blockers *and* releng flipped any necessary switches for 'release' behaviour. There's also a distinction in terms of the content of the compose: for an RC compose, the filenames and volume labels are supposed to be in the form of the 'final' release, whereas for TCs, the filenames and volume labels are supposed to indicate TC-ness. But so far as the actual test process goes, I don't think there's any need to distinguish them. Of course when it comes to Go/No-Go time we need to be sure the thing we're going-or-not-going-with meets all the 'RC' requirements, but it doesn't have to be explicitly labelled an 'RC' for that purpose, I don't think. For Pungi 4 I'm assuming the 'label' winds up in the image filenames and volume labels, though I haven't explicitly checked that. So I suppose if we went with a scheme that didn't distinguish between a TC and an RC, you couldn't tell just from looking at some random image's filename or volume label whether it was a TC or RC. But the value of this has always seemed quite small to me, since you also can't tell an earlier RC from the final release in this way; if you just have an image called 'Fedora 24' you don't know if it's actually the final release, or an earlier RC of the final release. The TC/RC naming was pretty much done for human consumption, but I'm not sure it really does much for us. > 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? Aside from the image naming, the primary difference is that the 'betanag' warning - the Timbuktu screen in the installer - is disabled. The point where we disable updates-testing by default is actually independent of the compose process, I think. > 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 Hmm, yeah, I like that more than 1 and 2 if we're gonna go that path, now you suggest it. 0 makes clear that this is something a bit different, and it lets us use '1' as the number for the solitary actual milestone release, which is natural. > 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 I think this still works a bit better if we add a 'Final' milestone rather than using the 'RC' milestone, but yeah, this isn't bad. Dennis, WDYT? I know releng has kinda treated Final a bit differently in the past; they basically left out all milestone-y indicators in Final builds (so they went into directories like 23_TC1 or 23_RC1, for instance, not 23_Final_TC1 and 23_Final_RC1, and the string 'Final' does not appear in their filenames or volume IDs). But I don't think Pungi 4 really allows for that, unless I'm missing something, production builds are required to have some kind of milestone identifier, so the question is only do we use the 'RC' milestone or add a new one, I guess. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
