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

James Laska jlaska at redhat.com
Fri Mar 5 13:49:37 UTC 2010


On Thu, 2010-03-04 at 21:06 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > I did explicitly explain to you and the other desktop SIGs at the start
> > of the F13 cycle that, because we just hadn't had time to discuss all
> > the thorny implications of the question, the desktop criteria would be
> > considered only with regards to the default desktop. Which is GNOME.
> 
> I don't think that makes sense. I didn't back then and still don't.
> 
> > The desktop criteria and validation tests did not exist before F13. It's
> > extremely unlikely we would ever have blocked any previous Alpha release
> > because graphical updating failed in *any* desktop. This reflects a
> > tightening of our release quality standards, not a loosening. In future
> > I'd like to have all the major desktops (KDE, XFCE, LXDE) considered as
> > well as just GNOME, but doing so in F13 would have been premature.
> 
> How would it have been premature to consider our 2 permanent spins equally? 
> Our users expect the KDE spin to be working.

Kevin, I understand your frustration.  Like everything, it's an
iterative process.  Nothing comes out of the gate perfect.  It takes
time to mature and develop into something everyone can be proud of.

At this point, my recommendation would be to follow the lead other spins
have done and actively engage the QA team to solicit testing against
your preferred spin.  Help provide the data needed to support any
decision around extending the existing release criteria.

> > I'd hope it would be obvious I *do* care, since I took the trouble to go
> > around to you and the LXDE and XFCE SIGs and ask if you'd have time to
> > kindly help fill in the results tables. By the same token, as explained
> > above, I *did* explain that we're unfortunately not considering the
> > results as binding on the release schedule for F13. However, having the
> > results is very useful for us all to know where the release stands, for
> > us to document significant issues in CommonBugs (I'll document the KDE
> > update issue there), and to establish the process for future releases
> > where hopefully it can become binding.
> 
> But why would I (or anybody else) be motivated to spend my time testing 
> things when I was told upfront that the results would be ignored?

Quality isn't something you staff and hope they cover all your testing
needs.  Quality practices are expected of everyone at all stages of the
process.  In the QA team, we work to provide a framework and guidelines
so people interested in making a difference have an opportunity to
succeed.  I can tell you are passionate about KDE.  I hope we can find a
way to convert this energy into something actionable that will provide
more insight into how the release criteria apply to KDE.

Thanks,
James


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100305/e2ad6628/attachment.bin 


More information about the devel mailing list