On Sun, 19 Apr 2015 00:07:48 +0200, Jerry Bratton wrote: > Then the policy that I suggest revising is the one which precludes automatically pushing at the +2 threshold. > There is no "one size fits all" with regard to security updates. Even if it were not a version upgrade, but only a small patch on top of a previously released version of the software, it's a new build that can break in lots of funny and not so funny ways. Sometimes software builds break because dependencies, tool-chains, frameworks have changed since the last released build. > Even requiring the lower threshold might arguably be too much. In any case, under the current system, users of Fedora 20 have been vulnerable already for 15 days. > Which, IMHO, is not true, because this update is available in the updates-testing repository. What is wrong with fetching it from there? Especially since you think it's good enough to be unleashed. Users of Fedora really need to understand that they are consumers of test updates in more cases than they may be aware of. All those Test Updates, which are pushed into the stable updates repo manually (i.e. with 0 karma and no explicit feedback from any testers, not even the packager) may have seen no testing at all. Really do take a look at updates-testing more often. Its contents are what may be installed on your machine tomorrow. And when it's broken in any way, users are annoyed. Take the opportunity to find the rare cases where an update is affected by regression or new bugs. Help making Fedora better. > Even if I were to vote on security updates that I noticed were taking a long time in testing, there's still the probability that there are many other security updates stuck in testing for a long time that I never know about, leaving my system vulnerable. > If tools like fedora-easy-karma worked flawlessly again (with an increased timeout value), it would be simple to vote on stuff that's installed on your machine. No need to know which packages are affected by updates or test-updates. fedora-easy-karma can tell you. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging