[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: What Fedora makes sucking for me - or why I am NOT Fedora



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]