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