First experience with F18-ALPHA-TC1

[Adam Williamson]

On 2012-08-14 5:26, Josh Boyer wrote:
> On Tue, Aug 14, 2012 at 8:21 AM, Adam Jackson <ajax at redhat.com> 
> wrote:
>> On 8/13/12 10:33 PM, Adam Williamson wrote:
>>
>>> It is a test compose of the Alpha. Alpha comes before Beta which 
>>> comes
>>> before Final. For each of Alpha, Beta and Final, we do test 
>>> composes and
>>> then release candidates. The first test compose of the Alpha is by
>>> definition the earliest and most likely-to-be-broken non-automated
>>> compose we ever create for a given release.
>>
>>
>> In fairness, many projects choose not to abuse nomenclature like 
>> this.
>> Seeing announce messages saying ALPHA HAS GONE GOLD makes my skin 
>> crawl,
>> too.  Alphas are not gold anything.
>>
>> It would be far more honest to just call this alpha 1.
>
> fwiw, I agree.

We've discussed various ways to re-jig the structure in the past, but 
something that simplistic certainly isn't it. We have specific 
requirements for the Alpha, Beta and Final releases: they _must_ meet 
those requirements in order to be shipped. The TCs and RCs are 
absolutely not intended to be general test images (though they sometimes 
get abused in that way), they exist for the specific purpose of doing 
validation testing to ensure the 'official' Alpha, Beta and Final 
releases meet the requirements. Note that for a long time, the TCs and 
RCs were not distributed outside the RH VPN, partly to avoid this kind 
of confusion. I think it's correct that we now _do_ distribute them 
publicly, but note that we do not use the full Fedora mirror structure 
for this and we do not make a proper press announcement of them: they 
are officially announced _only_ on this list, and the announcement mail 
makes it very clear that they exist for the specific purpose of doing 
validation testing.

I think we actually have a very strong process in place here, which is 
clearly defined and achieves useful goals: you can go look up the Alpha, 
Beta and Final release criteria - call them 'release definitions' if you 
like - and know with reasonable certainty that you're getting the 
functionality described there, at a minimum, when you download a Fedora 
Alpha, Beta or Final release. If we just slapped 'Alpha X' names on the 
TCs and shipped them, you'd be in a much more uncertain state. F18 Alpha 
TC1 is actually an excellent example of this: it does not boot at all, 
and even if you hack the kernel command line to make it boot, anaconda 
fails to initialize and there is absolutely no way you can hack around 
that. In other words, Alpha TC1 is functionally useless, it is DOA. I 
can see no possible benefit to the project in shipping out such an image 
to the general public with an 'Alpha 1' label on it, it would do nothing 
but harm to Fedora.

We _need_ to generate such DOA images: we wouldn't know if a Fedora 
image composed from the F18 tree of yesterday would be bootable and 
installable unless we _generate such an image and try it out_. By the 
principles of Fedora, such test images should be made openly available 
to the Fedora QA community, not just to Red Hat staff. But it doesn't 
serve the interests of the wider public to have such test images pushed 
out as if they were 'proper' pre-releases. They really aren't. They're 
test builds.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net