jwboyer (jwboyer) wrote,
jwboyer
jwboyer

The updates conundrum

I have been the primary update pushed for Fedora for about 2 months now. Having done this every week day for that long has led me to some completely subjective opinions on updates, release lifecycles, and the health of our update system (from an admin point of view).

Overall, we have a lot of updates. The metrics page shows a decreasing trend the longer the release has been available. This is generally good, but there are still a very large number of updates that make me scratch my head when I see them, either because the update lacks any useful information at all, or because the update itself seems to make little sense in a stable releaes. Jesse Keating tried to highlight some of these questionable updates but it seems he was either ignored or berated for being "heavy handed".

When I see a package update submitted that just takes a package to the latest upstream release, I always question it in my head (and sometimes in the update). I realize that upstream releases often fix bugs that effect users, however the update should say that at a minimum and it generally doesn't. Many times there is an update like this that seems to just be 'because it's the newest!' Which leads me to my next annoyance.

Fedora doesn't have a rolling release. We have a large number of contributors that work rather hard at keeping with the various package freezes, mass rebuilds, and other administrative work that goes along with creating a release from rawhide. Yet after that release has GAed, we seem to sort of throw that out and just submit updates for updating's sake. It is not uncommon for a package to have identical versions in the three active releases. It is not uncommon to have a brand new package submitted to all active releases at the same time. While I'm quite aware of some of the reasoning behind this, I still question the practice of doing that. And it boils down to this: What value does that add?

Honestly, I have found myself running yum update not because I have problems. Not because I need some new package, but just because 'yum update' is habit (security updates aside).

So... why do I care? Because it adds churn that doesn't seem to be needed. It adds churn to the mirrors. It takes longer and longer to mash the updates repos. It requires more time to sign all the updates. And honestly, it causes churn for our users.

The one benefit (and I say that in a sort of silver lining way) that has come from this is that it has helped me understand some of the weak points we have in the updates process, both in the bodhi backend code and just the actual process. Things like

1) We need more people that understand the bodhi code from front to back. Luke Macken is amazing at fixing things, but I think he would agree that it sucks when I ping him on IRC because bodhi failed a push. I'm getting better about this, but it's an example of a 'single point of fixing'.

2) We need to make the bodhi code a bit more resilient and/or verbose in error messages. Things like revoked updates during certain stages of an updates push can cause hassles and delays.

3) We need less updates. Oh, I already said that.

Well, I see a pile of updates to go sign. Guess I should stop ranting and get back to being part of the problem ;)
Tags: fedora
Subscribe

  • Flock Krakow 2016

    The annual Fedora contributor's conference, Flock to Fedora, wrapped up last week. From everything I've seen and heard, it was a smashing success.…

  • Time for an Alternative

    I've been doing kernel development or maintenance for a large portion of my professional career. It started at my previous employer and continued for…

  • When is a kernel bug not a kernel bug?

    Think of this scenario: You're sitting at your shiny Fedora install and notice a kernel update is available. You get all excited, update it through…

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 3 comments