Re: Pungi 4 milestone builds: proposals
On Wed, Mar 9, 2016 at 11:16 AM, Adam Williamson
<adamwill(a)fedoraproject.org> 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