A note on validation event and compose versioning

Fri Feb 13 22:33:12 UTC 2015

Hey, folks. This is kind of a 'philosophical' side-note on versioning 
that comes out of my work on the release validation stuff, wikitcms, 
and fedfind. It's quite detailed so skip it if you like :) But I 
wanted to at least write it down somewhere for future reference. Those 
following the relval/wikitcms/fedfind/openqa work may find it useful.

While gluing openqa to fedfind to python-wikitcms to relval, I seemed 
to keep running into cases where the 'sensible' approach to 
identifying the 'version' of something didn't seem to match up between 
components.

For everything but Rawhide, it's actually pretty easy. We can identify 
'composes' with this version scheme:

RELEASE [MILESTONE] [COMPOSE]

RELEASE is a Fedora release number - '21', '22', '23' etc. MILESTONE 
is Branched, Alpha, Beta, or Final. COMPOSE is either a date (for a 
nightly build), or a TC/RC identifier.

This works, AFAICS, for all composes except Rawhide, regardless of 
whether you're talking about a compose, an image, or a release 
validation event. Some examples:

21 Branched 20140806
18
14 Beta
22 Alpha RC3
13 Beta TC1

For any of those, there could be a compose, some images, and a release 
validation event, and we can use the same version identifier to talk 
about all of them, and all the tools can use the same variable names 
and identifiers and stuff. Great.

The tricky case is Rawhide nightlies.

When I set up the new nightly compose approach for F22, it seemed to 
make sense to set up the naming following the above scheme, with a 
release number and 'Rawhide' as the milestone. So to wikitcms and 
relval the version of the 'current' event is '22 Rawhide 20150207'.

When I built fedfind - the thing that finds *images*, i.e. it doesn't 
concern itself with validation test events - that didn't actually make 
any sense at all. If you look at the details of finding Rawhide 
nightly *images*, there's never a version number. There isn't one in 
the Mash URL where the boot.isos and packages live. There isn't one in 
the Koji tasks.

So I built fedfind to treat 'Rawhide' as a *release*. To fedfind, the 
version for the images for the current validation event is something 
like 'Rawhide 20150207'. Which worked fine for fedfind, but led to 
dissonance whenever I tried to do something with both wikitcms and 
fedfind.

I sort of mentally fought with this for a while and came up with ways 
to handle it, but I didn't really have a good mental model of what's 
going on. This morning though I think I've got a good way to think 
about it.

Here's the thing: Rawhide nightly *composes* - the tree and images - 
don't have a release number. It's not just that we can ignore it for 
fedfind's sake, they really don't have one at all. Rawhide is a 
rolling distribution. The correct way to think of the 'version' of any 
incarnation of Rawhide that gets frozen in time somehow - an image, a 
tree - is 'Rawhide DATE'.

However, *validation test events* for Rawhide nightly composes *DO* 
have a Fedora release number. We effectively 'apply' a Fedora release 
number to the validation test event at the time we create it. 
Conceptually speaking, when we do that, we are making a declaration:

"Given our knowledge of the Fedora release process, we declare that 
testing the Rawhide nightly images for this date forms a part of 
release validation testing for this future Fedora release number."

When I started thinking about things this way, it started to get a lot 
clearer. So this morning I've been kinda refactoring things in all the 
tools - relval, python-wikitcms, fedfind, and my pending patches for 
openqa_fedora_tools - to follow this conception.

I'm going to try and make it so that absolutely any time you talk 
about a *release validation event*, the RELEASE [MILESTONE] [COMPOSE] 
pattern applies. RELEASE is mandatory and is always a Fedora release 
number. MILESTONE is Rawhide, Branched, Alpha, Beta, or Final. COMPOSE 
is TCn or RCn (where n is a number) for Alpha/Beta/Final, a date in 
YYYYMMDD format for Rawhide/Branched.

When you talk about a *compose*, the same format applies for 
everything except Rawhide, but for Rawhide nightlies, the version 
format is:

Rawhide YYYYMMDD

There are currently bits of relval and python-wikitcms that use 
different names for what are essentially 'MILESTONE' and 'COMPOSE':

Milestone: 'tree', 'build'...
Compose: 'date', 'version'...

I'm going to basically throw all those out and standardize on the 
names 'milestone' and 'compose'. Note one significant exception to 
this - the wiki templates will still have separate 'date' and 
'compose', with 'date' set for nightly events but 'compose' set for 
TC/RC events. This is because wiki template syntax is pretty limited - 
it's not really capable of reading a single value and deciding whether 
it looks like a TC/RC identifier or a date. We have to be able to do 
something like 'if there's a value for date, do (nightly thing), 
otherwise do (tc/rc thing)'.

They're a *bit* strange as names when applied to a branch and a date, 
but at least it's always consistent and you don't have to remember 
different terms. Note that python-wikitcms now has two new methods 
Wiki.get_validation_event() and Wiki.get_validation_page() which will 
give you a correct ValidationEvent or ValidationPage instance for a 
given 'release', 'milestone' and 'compose' regardless of whether 
that's a Rawhide nightly, Branched nightly or TC/RC compose. It also 
does guessing for *existing* nightly events - you can just give it a 
release number and a date and it'll return whichever of Branched or 
Rawhide exists for that date.

I'm trying to make the tools as 'frictionless' as possible so you can 
pretty much always pass the right values with the names 'release, 
milestone, compose' and things will work. Notably, 
fedfind.release.get_release() should be 100% compatible with the 
'validation event'-style naming. *Even for Rawhide nightlies*, you can 
do get_release(release=22, milestone='Rawhide', compose='20150212') 
and it's smart enough to give you a RawhideNightly. But you can *also* 
do get_release(release='Rawhide', compose='20150212'), or 
get_release(milestone='Rawhide', compose='20150212'), or simply 
get_release(date='20150210') and get the right thing. To get Branched, 
you'd do get_release(release=22, compose='20150212') or 
get_release(release=22, milestone='Branched', compose='20150212').

You will *usually* be able to parse a fedfind object's 'version' or 
'release', 'milestone' and 'compose' properties into the matching 
release validation event-style version, but you will *not* be able to 
parse a fedfind object for a Rawhide nightly compose in this way, 
because as we saw above, Rawhide nightly composes *do not really have a
release number*. The 'release' property for fedfind Rawhide nightly 
objects will always be 'rawhide'.

Anyway, hope that explains things for anyone who's interested and I 
can always use this as a reference later :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net