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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
