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

[James Laska]

On Thu, 2010-03-04 at 10:47 -0800, Adam Williamson wrote:
> On Thu, 2010-03-04 at 14:17 +0100, Kevin Kofler wrote:
> > James Laska wrote:
> > > Representatives from Fedora QA, Rel-Eng and Development met on IRC to
> > > review determine whether the Fedora 13 Alpha release criteria [1] have
> > > been met.  The team agreed that the Alpha criteria have been met, and to
> > > proceed with releasing F-13-Alpha-RC4.
> > 
> > Oh, because a KDE live image which can't be updated without resorting to the 
> > command line is <SARCASM>obviously</SARCASM> ready for release, and because 
> > there was <SARCASM>clearly</SARCASM> no way a RC5 could have been spun in 
> > the several days between the availability of the updated kpackagekit build 
> > (to match the PackageKit snapshot used in RC4) and this meeting.
> 
> 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.
> 
> 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.
> 
> I would have liked to do a respin of the KDE live image with the new
> kpackagekit, and we did have a brief discussion with releng about that
> at the initial go/no-go meeting, but we kind of dropped the ball in the
> next few days on that, for which I'm sorry. It wasn't intentional.
> 
> > 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. =)
> 
> > But of course the GNOME spin "works" (for some definition of "works", they 
> > also have a PackageKit issue which was declared not a blocker – 
> > https://bugzilla.redhat.com/show_bug.cgi?id=567346 , which I guess also 
> > affects KPackageKit, by the way –, 
> 
> Yeah, it probably does. It's been declared not-blocker because it's
> ultimately caused by the langpacks plugin, so there's an acceptable
> workaround - uninstall that - which is documented on the CommonBugs
> page. Also, it will only happen in a case where there's dependency
> problems, so when the available F13 update set is actually *coherent*,
> it won't fail.
> 
> > and they fail pretty much all the tests 
> > for beta or release quality, which I think the KDE spin would actually pass, 
> 
> Yup. We don't block Alpha release if it fails the criteria for Beta or
> Final. That's the pre-release process working. =) If you look at the
> linked bug reports, most of the failures are fairly minor. For instance,
> one test 'fails' because if you open System Tools - CD/DVD Creator, drag
> in some files and hit 'burn', it crashes nautilus instead of running
> Brasero. You can easily run Brasero directly and burn a disc, though.
> I'd hope you'd agree that's a perfectly acceptable level of
> functionality for an *Alpha* release.
> 
> > given that this is the same 4.4.0 we pushed as F11 and F12 updates and works 
> > fine there, though I didn't bother testing this as clearly nobody cares 
> > about the KDE spin test results anyway), so nobody cares.
> 
> 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. Also, if any of the non-default
> desktops had been known to be really horribly broken - as in, 'the damn
> thing won't start up', or something - we would have considered making
> that an Alpha blocker.

To re-emphasize a point Adam made above, users of other desktop
environments are strongly encouraged to participate in community test
runs during release milestones.  As it stands, we have one test result
[1] from the a desktop environment other than GNOME.

While it was explained that the release criteria do not pertain to all
desktop environments for Fedora 13, it would really help to have a more
complete picture of how the criteria might apply to other desktop
environments.  Without the data, it makes deciding whether to extend the
release criteria to these environments a difficult decision.

Thanks,
James

[1]
https://fedoraproject.org/wiki/Test_Results:Fedora_13_Alpha_RC4_Desktop
-------------- 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/20100304/b5ee8fd0/attachment.bin