On Fri, 26 Feb 2010, Jesse Keating wrote: >> +1. Not being able to push those out quickly would really suck. > > What sucks more is recent "hot-fixes" which were even more broken than > the issue they were trying to fix. They were pushed directly to stable > and broke a significant number of systems because of a scenario the > maintainer didn't imagine or test. I can see both sides here, having been part of a big disaster recently (which might have been the cause of this discussion at FESCO). Let me describe what happened in this case, so people can see these issues can get very complex. Due to delays in getting a fedora package updated (purely my fault) the dnssec-conf package had expired DNSSEC trust anchors. This caused a denial of service attack by Fedora servers against various important nameservers at RIPE. This change was not due to a package update, but due to a missing update. This needed urgent fixing, as in someone called me at 4am. I got together with the bind maintainer, prepared an update and we both tested it. It worked for us. I had this tested on devel, F-12 and EL-5. I requested a direct push to stable. Which was denied. I was unhappy that we would not stop a DOS attack within weeks (my packages hardly ever get any karma feedback despite their obvious use, though I must say that did change for dnssec-conf after it blew up). So I objected, and got my way. A push to stable happened, and something went wrong. It turned out that anyone who had upgraded from F-10/F-11 onwards had a configuration file in an old location. Testing should have seen this, but we didn't. In this case the result was bad, though not worse without the update. Without the update, the bind nameserver would be DOSing RIPE (and not work very well as a nameserver because it was too busy). After the update the nameserver failed to start with an error in a few include statements to non-existing files that was annoying but fairly easy to fix even for non-developers. The fix for that was pushed into testing. I did not dare to request going straight to stable again, though objectively looking from a policy statement, that's what should have happened to avoid people upgrading to the broken release. Looking back at this, the ideal solution would have been to involve a few people in testing/approving the direct-to-stable push. I believe this is what Fesco is thinking about with a Fesco/releng/QA. Whether you call this an "expediated push from testing" or a "direct push to stable" is really semantics. What's important is that there are resources that can take on a "hot fix". I don't know where we can get those resources, as Fesco seems pretty busy as it is. Summary: Blocking direct-to-stable is fine, as long as requests to override it are taken seriously and somehow the package gets some additional attention from someone beside the packager. It all comes down to human resources.... Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
