Release management strategy for Alpha releases ("Tribes")

[(``-_-´´) -- Fernando]

On 8/17/07, Matt Zimmerman <mdz at ubuntu.com> wrote:
> On Mon, Aug 13, 2007 at 12:47:27PM +0200, Martin Pitt wrote:
> > Small approach: We can regard it as a mere snapshot in development,
> > with barely enough effort to make it installable. But in this case we
> > should not advertise them so heavily (4) and e. g. only write about
> > new features on the Beta release notes and web pages. The main focus
> > would be to exercise the installer and test the kernel on a broad
> > selection of hardware.
>
> Early alphas can't be much more than this, and should be characterized as
> such.  They're snapshots of a fast-moving target, and will have known
> problems which aren't important to fix at this stage.
>
> I don't agree that we should be less communicative about them for this
> reason.  They will contain new kernels, new X drivers, and a variety of
> other bits and pieces which need to be tested, and tested early.  Much of
> this can be accomplished simply by booting the live CD and providing
> feedback, even if the user doesn't install it.  Proper testing of these
> changes requires broad participation, and we only have a chance at that when
> lots of people hear about it.
>
> > Big approach: We regard them as a mini-release which we want both
> > developers and advanced users to test, where new features actually
> > work properly and which we can be proud of. We would focus on
> > presenting them well instead of presenting them as fast as possible.
> > Then we must concentrate on bug fixing and radically reject new
> > features which have not matured enough so at least work for ourselves.
>
> Later alphas are more like this, and folks can expect to install them if
> they plan to track the development branch, etc.  Their primary purpose is
> still testing, though, more so than showcasing features.  It's not until the
> beta release that we should promote these features for general consumption
> and evaluation (as opposed to testing).
>
> --
>  - mdz

I have the exact feeling whne dealing with alphas from Ubuntu.
Tribe 1 and 2 tend to work with breaking too much (althougt sync
isincomplete, so the previous repositoire is needed). Later Tribes
(3/4) tend to break all the time, with major update daily from then
on.

Thats why I said (dont know if the message reached the list) that I
rather have less Tibes, but more tested ones. So I'm in favor of the
big approach.

-- 
BUGabundo  :o)
(``-_-´´)
Linux user #443786    GPG key 1024D/A1784EBB