On 2012-08-14 5:26, Josh Boyer wrote:
On Tue, Aug 14, 2012 at 8:21 AM, Adam Jackson <ajax@xxxxxxxxxx>
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
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
