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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
