Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
disable automatic karma push when there is any negative karma #833
We sometimes have updates in which many people give +1 because they see no issue, but as many people give -1 because they see a serious issue. Like this one, when translations broke for non-english speaking users:
The problem is that at some point the amount if +1 votes can reach the auto karma push threshold and the whole update is going to get pushed to stable, even though there are many many -1 votes for that update as well and it should definitely not go stable, at least automatically. This happens randomly, as different people test this (it can easily happen that the first two people have an issue and give it -1, then five users give it +1 "works for me", and before another affected user can give it -1, it's already scheduled for stable and we can't do anything about it).
If the maintainer doesn't watch this update closely and doesn't react in time (maintainers sometimes also sleep), we end up with broken software shipping to all our users. In my QA experience I've seen this happen repeatedly, sometimes trying to reach to a maintainer to not succeeding in time, sometimes seeing this after it happened.
Please let's fix this. I believe that once a -1 karma is given to a particular update, it should disable auto karma push. The unpush value can stay the same (it still makes sense to unpush an update automatically when many people report issues), but the push stable value should be reset to 0 (or whatever value means "disabled"). In other words, once we received a failure report, we should never push software automatically to all our users, it should always be a conscious decision of the package maintainer. It would be nice it this change was reflected inside the update (e.g. added a new bodhi comment
A nice final touch would be to re-enable push to stable if all users who gave -1 karma amended their vote and changed it to +1 (i.e. there was some confusion and it was cleared). However, that's probably more difficult to implement; a basic implementation as described above would be completely sufficient and would improve quality of Fedora updates quite a bit.
Thanks a lot.