Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

[Adam Williamson]

On Thu, 2010-03-04 at 14:22 -0500, Toshio Kuratomi wrote:
> On Thu, Mar 04, 2010 at 10:47:28AM -0800, Adam Williamson wrote:
> > On Thu, 2010-03-04 at 14:17 +0100, Kevin Kofler wrote:
> > > On one hand we have people complaining about the quality of updates, on the 
> > > other hand we're happily releasing crap we know is broken.
> > 
> > It's an *alpha*. 'Crap we know is broken' is more or less the definition
> > of alphas. =)
> > 
> Just a clarification point:
> 
> http://fedoraproject.org/wiki/Alpha_Freeze_Policy
> #  At Alpha Milestone, all packages should testable and feature
>   complete--whether they are "official features" of the release or not 
> 
> So broken, yes.  But the extent of breakage is important.  Breakage that
> results in core components being untestable would seem to be blockers under
> the current policy -- the result of discussing them would be whether to get
> an update into the Alpha Release, revert the broken package, or simply ship
> with the untestable piece documented and remember to add more extensive
> testing for that at a later point in the cycle.
> 
> (Pointing out since F-12 cycle we had people confused about what was
> expected of the Alpha release).

We have various different definitions of the Alpha, it seems. The
working definition that QA / rel-eng have always worked on when deciding
whether to ship it is, broadly, 'can you install it, boot it, get a
network connection, and install updates'. That's what the current Alpha
release criteria and validation tests aim to explicitly codify and
verify.

I'm not particularly sold on the definition in the freeze policy, and
honestly I suspect it's been honored much more in the breach than in the
observance. I'd be very surprised if all planned features of a given
release have ever been fully 'testable' in our Alpha releases. Frankly,
that seems like an unrealistic goal given the timescales we work with,
depending what definition of 'testable' you want to take (there's a huge
amount of wiggle room in that word).

I'd say our practical take on it is that the freeze policy definition
means the maintainers should basically have the major chunks of code
that they're aiming to ship in place by Alpha, but if there's a bug
making it not possible to really use some of them in practice - but that
bug doesn't stop the basic 'install Alpha, get updates' procedure from
working - we're not going to hold the release for that.

To give a practical example, if 'KDE X.Y with shiny new IM client' is
listed as a feature for the Alpha, we'd say the freeze policy requires
the new IM client should actually be present in the Alpha package set.
But we wouldn't say the release should be blocked if there's a bug which
causes it to fail to launch, even though this arguably makes it 'not
testable'. The theory is that there's no point holding the Alpha release
to fix something we can fix equally well in post-Alpha updates, since
there's no net benefit to anyone. But we should probably discuss this in
more detail.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net