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

[Toshio Kuratomi]

On Thu, Mar 04, 2010 at 12:01:42PM -0800, Adam Williamson wrote:
> 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).
> 
We should change or refine the Freeze Policy page then.  Having different
definitions of what is required for alpha to go out and what can go in after
alpha leads to incorrect expectations on the part of developers.

> 
> 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.
>
Big +1 to that.  I don't care too much what the criteria is as long as its
consistent and doesn't put package maintainers in an impossible position wrt
getting their development done and into the next release.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100304/3c4a7e3f/attachment.bin