Better educating about what Alpha, Beta, Release means

[Robyn Bergeron]

On 09/15/2012 07:20 PM, Adam Williamson wrote:
> On 2012-09-15 10:47, Stephen John Smoogen wrote:
>> I am seeing a LOT of confusion about what Alpha, Beta and Release
>> levels. Several people saw the world GOLD and thought that it meant
>> this was the final release.. other people saw Alpha Release Candidate
>> and got the same impression. Some of this may be user education and
>> some of this is our naming conventions. I don't know how to deal with
>> the naming conventions so leave that bikeshed for someone else to
>> paint.
>
> I agree the current conventions could be improved. We really should 
> get around to this between 18 and 19. We have various proposals lying 
> around in the list archives for changing the naming of RCs and TCs, 
> and we also have proposals for changing the blocker bug aliases (kinda 
> related). I also agree we should stop using the word 'gold' for Alphas 
> and Betas (for the record, QA does not do so, it comes in with the 
> release announcements, which are FPL/program manager stuff.)
>
>> Here is my view of what the release levels mean to me. It probably
>> doesn't follow the official guideline but it helps me figure out where
>> and what to do with it.
>
> What we have that's 'official' are the objectives listed on the 
> criteria pages. I'll paste these under your descriptions, for comparison.
>
>> Alpha -- Is not a reliable OS for production or for long term
>> development purposes. In the old parlance, will eat kittens and laugh
>> when told not to. It is meant for testing only in order to get people
>> to find the obvious bugs and such. Use on spare hardware or hardware
>> that you have made a complete backup before and then can reinstall
>> afterwords. Upgrades from Alpha to any other release may work or they
>> may choke and die.
>
> The objectives of the Alpha release are to:
>
>     Publicly release installable media versions of a feature complete 
> test release
>     Test accepted features of Fedora 18
>     Identify as many F18Beta blocker bugs as possible
>     Identify as many F18Blocker blocker bugs as possible
>
>> Beta -- is not a reliable OS for production but more reliable than
>> Alpha. In the old parlance, it may eat a kitten and then look
>> remorseful afterwords. It is meant for testing but should be able to
>> be used for day to day usage til the release candidate comes out.
>> Upgrades from Beta to Release may work or they may choke and die.
>> Upgrades from an old release to Beta should work.
>
> The objectives of the Beta release are to:
>
>     Publicly release installable media versions of a code complete 
> test release: Beta is the last widely co-ordinated test release point 
> in any given release cycle
>     Finish testing Fedora 18 Features
>     Identify as many F18Blocker bugs as possible
>
>> Release (or Gamma in my head) -- a reliable OS for production usage
>> but may cough up a furball or two. It can be used for day to day usage
>> and should be good til the next Release or 2 if you want to take a
>> break from testing. Upgrades from Release to Release should work.
>
> The objective of the Final release is to:
>
>     Provide a polished final release suitable for meeting the needs of 
> our Target Audience
So maybe one idea here, that I was thinking about while adding some of 
the known bugs to the release announcement....

We always have a section in the release announcement about "what is the 
alpha (or beta, etc) release?" - and we basically say, "Oh, it's a 
release, and then it gets better."  And I wonder if it might make sense 
to have something that outlines things like this, either on the wiki, or 
copyable from wiki for release announcements, etc:

* What is a Beta/Alpha (or even test candidate, release candidate)?
* Is the Beta Release (or alpha, etc.) for me?
* You should definitely try out the Alpha/Beta if....

With content like....
* What the user should ideally be familiar with, technologically; 
running things in a VM, able to copy to a USB key, comfortable with 
configuring disk partitions, whatever.  Recommending that people trying 
TCs, RCs, etc. be familiar with filing bugzilla reports.
* If we recommend installing it on your primary system (ie: We probably 
wouldn't recommend installing a test candidate for alpha to your machine 
if it is your only machine and you need it every day for your job.)
* If you are a feature owner, you should try out test candidates, 
release candidates, and all officially declared release versions, to 
determine _____________. if you are an upstream project maintainer, 
__________etc.  If you care about Fedora, and can follow relatively 
simple instructions, you should try out the Beta release.

The key is to present it gently without scaring people off; I don't 
think the bar is *that high,* and we certainly don't want to discourage 
people from trying it out, but at the same time - if we're in a 
situation where commonbugs lists hairy workarounds, it might be useful 
to draw a line, or at least relate what the user should be comfortable 
with before embarking.

Thoughts?

-r