Kevin Fenzi wrote: > I don't recall the example Adam mentions, but I have no reason to doubt > it. I don't recall it either, so that's already 2 people. And I tend to remember such things. So you should in fact doubt it. Do not believe everything you read on the Internet! > How about the dbus security update that went directly to stable and > broke everyones dbus using services? > > http://lwn.net/Articles/311146/ > http://lists.fedoraproject.org/pipermail/announce/2008-December/002572.html This had a one-line command-line workaround (to get the fixed package over the yum command line, working around breakage of the GUIs). > The current policy came out of a bunch of breakage in 2010... It actually came out of a single bad "bind" update, affecting the BIND server only (not the client libraries), a package that the vast majority of Fedora installations does not even have installed to begin with. That issue was also perfectly fixable by just SSHing into the affected machine by IP address (and you definitely SHOULD know the IP addresses of your servers! Or at least you will be able to find them out) and running "yum update". The really fatal update issue in 2010: https://fedoraproject.org/wiki/Updates_Lessons#2010-07-07_-_PackageKit_not_showing_updates_anymore actually happened WITH the new policy, proving that it does not work, at all. (And also that SELinux breaks things, but nobody other than me even considered disabling SELinux in response.) In addition, before the Bodhi policy changes, in such cases, it was possible to push the fixed package directly to stable, minimizing the exposure time and thus the number of affected users. This is also made impossible by the new policy, so you end up with more users getting hit by the fatal regression, and the fix is harder to get (one has to enable updates-testing). Not to mention other fatal side effects of the policy such as: https://fedoraproject.org/wiki/Updates_Lessons#2010-11-11_-_proftpd_remote_code_execution_security_update_delay of which there were (and still are!) actually dozens of instances, but nobody wrote them down after the first. Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
