Did we really release 8.04?

[Matt Zimmerman]

On Mon, Jul 07, 2008 at 08:30:28AM -0400, Scott Kitterman wrote:
> This is not sustainable in the long term.  Before long people will be 
> saying, "Everyone know not to upgrade Ubuntu until the first point 
> release".  Then we don't get the end user base to test until .1 and we have 
> to bugfix from there.

While this is a natural assumption, if you think about it a bit further, I
think you'll agree that this is not the case in practice, because we don't
have a single "end user base" which behaves consistently.

Ubuntu serves a wide variety of different users, who have different
expectations and levels of willingness to participate.  These range from
hard-core developers who are already running Intrepid, through power users
who may upgrade during the beta period, through enthusiasts who will upgrade
as soon as a new release is out, through casual users who will wait until
later, to conservative users who will only consider LTS.

By orienting our quality processes toward these different groups, we allow
our users to choose their own tradeoffs between stability and timeliness.

> Once 8.04 was released and its problems became apparent, then fixing it was 
> needed and the response from Canonical is laudable.  We need to find a way 
> to avoid repeating the experience.

The 8.04.1 point release was planned, and the supporting team organized,
long before 8.04 itself was released.  It was not a reactive move, but a
well-considered change in our approach to LTS.

> Personally, I'd like to hear users saying, "Yes, I know it's beta, but
> it's an Ubuntu beta so I'm sure it's fine."

There is one class of users from whom we would like to hear this.  But there
are also those from whom it's appropriate to hear "That's a brand new
release, I'm not going near it until the first point release!"

> I think the only path to better tested releases is higher quality test 
> releases.  I suspect more discipline about feature freeze is a part of it, 
> but I don't know what else?

There is no single path to quality; we should segment our approach and
employ the best methods for each stage of stabilization.  During alphas,
this might mean focusing on installation and hardware testing; for the beta,
engaging a broad community of testers to use the new release for their
everyday work; for an LTS release, to have comprehensive point releases to
fix issues which weren't caught by testing, etc.

-- 
 - mdz