Jon Stanley wrote: > I agree that this is unfortunate, and also note that Ubuntu does a > better job than we do in this area, with a menu to select the language > when booting the Live CD. Maybe something that could be worked on. If > you have experience, feel free to pitch in! I've not engaged in a > comparison between the Ubuntu Live CD and ours, however I'm assuming > that they sacrifice a lot of functionality on the Live CD in order to > have room for the various languages. Everything is a trade-off, > unfortunately. I can't speak for the GNOME Live CD, but as far as the KDE Live CD is concerned, there's no way we can fit in all the kde-l10n-* packages and still fit on a CD. We'd have to make it a DVD and that would screw over the people with older computers (which is what another of Robert's complaints was about). So there's a tradeoff between supporting older computers or translations. > No need to kill bodhi, simply implement a signing server in a secure > fashion. Well, Jesse Keating recently said the signing server won't solve all the issues by itself, because one of the problems is that each push takes about 24 hours to complete. We would get one push per day with automated signing, but no more, unless Bodhi gets optimized somehow (but it isn't immediately obvious how). But I don't think killing Bodhi is the solution nor even an option. >> When talking about PackageKit, DBUS is another issue. The recent DBUS pkg >> update broke PackageKit stuff - thanks to our cool QA. And clever as we > > Unfortunately I don't think that I can tell from bodhi what the > initial request for this particular update was, testing or stable. I > suspect stable, since it was a security update, and it was pushed > within 2 hours of the update being submitted. Therefore, there was no > opportunity for QA. However, QA is an area where we are desperately > lacking resources. Help is welcome there. Well, the problem here is that the update was rushed to stable when: * the update touches a core system component which is relied on by our update system among many other things, * the update is not one of those obvious security fixes like preventing a buffer overflow, it is a policy change (and thus much more likely to break things), * the policy crackdown is on local communication, not remote. This means: - it is more likely to break the system and as such needs testing and - the hole it fixes is at most a local privilege escalation, and finally * the issue has been public for over a month! What is one more week of testing going to change? I think we need to be more careful with certain types of security updates, and better let them get some QA even if it means the fix gets delayed. Completely breaking the updates means many users will never get any updates anymore (because they don't know how to fix their system - there's a PackageKit update queued, but how are they going to get it without a working PackageKit? You can't expect them to know what su -c "yum upgrade" is), including critical security fixes. Is a low-priority security update worth that? At the very least the maintainer should actually test the update before rushing it out, which I strongly doubt he did because PackageKit not working is something everybody should notice. (But I don't think that's sufficient, I think the update should have stayed in updates-testing for a week. And ideally both should have happened, the maintainer should have tested it first, and only when actually working pushed it to testing.) If I'm not mistaken, there's also a problem with how our "security team approval" process works, because the security update requests all show up as requests for testing first, then the security team approves them and queues them for stable, so the maintainer has to explicitly tell them not to do that if he wants the update to get some testing first. Oh, and it wasn't pushed within 2 hours of being submitted, the date you see is the "Date released", not the "Date submitted". Normally "Date released" is the date and time the update gets pushed, but the 2 hours of difference are because the "Date released" gets set earlier in the pushing process than the "pushed to stable" comment. If you look at https://bugzilla.redhat.com/show_bug.cgi?id=474895 you'll see it took 32 hours to get the update pushed. It is impossible for an update to be pushed within 2 hours of submission because the push alone takes about 24 hours. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
