The updates conundrum
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 ;)