Bernd Bartmann wrote:
Every of the missing announcements is much longer than 2 days out. Here are the dates when the files appeared on the download mirror that I use: perl-5.8.5-11.FC3, released 2005-04-27, #156366 logwatch-5.2.2-1.FC3.1, released 2005-04-26, #156367 devhelp-0.9.2-2.3.2, released 2005-04-22, #156017 epiphany-1.4.4-4.3.2, released 2005-04-22, #156016 mozilla-1.7.7-1.3.1, released 2005-04-22, #156015 logwatch-5.2.2-1.FC3, released 2005-04-21, #156014 firefox-1.0.3-1.3.1, released 2005-04-19, #156013 postfix-2.1.5-5, released 2005-03-17, #151588 nfs-utils-1.0.6-52, released 2005-02-19, #149901 Up to now I have no script to monitor the missing announcement. I'm still hoping that this problem is addressed in a way so that it cannot happen again. I just take a look at my rsync mirror logs and compare them to the announcements that appeared on the mailing list. If no announcement comes out within two days after the rpms appear on the download mirror I open up a bug in bugzilla. So far most rpm packagers were helpful and sent out the announcement when they see the bugreport. But sometimes even this fails :-( Why is it not possible to automatically sent out the announcement after the rpms are signed and the MD5 sums are known? Is it possible to trigger an email to the packager after the package is signed? Something like a reminder "package is ready for distribution, please sent out an announcement".
Taking several steps back to look at the forest instead of being unable to see it for all the trees ... The more reliance a given "system" has on human beings to perform a set of steps, the more room said system has for human error. The current fedora-update mechanism is currently entirely human driven with almost zero automation, unlike the errata mechanisms used for Red Hat Linux in the past, and Red Hat Enterprise Linux currently. What the Fedora Project needs right now to "solve" this and other problems related to errata, is an automated errata tool system that handles as much of the process as can be automated, leaving the engineer to do developmental engineering and maintenance instead of doing manual human release engineering. There are different potential solutions, but the first thing that comes to mind, is a web based CGI solution, which allows an engineer to open an erratum ticket, file some initial basic details summarizing the problems being addressed, the nature of the issues (security fix, bug fix, enhancement), and then be able to follow each step of the errata release process one at a time through to final release of packages. The process should handle the creation of the advisory text, and references to CVE names and other URLs related to any security problems or bugs being fixed. There should be a field to indicate which Red Hat bug IDs are being fixed in the update. There should also be a way for the engineer to point the errata CGI to the generated rpms, and to request that they be signed by those who have RPM GPG signing priveledges. Once the rpms are signed, the next "state" in the process would be errata advisory text approval - how this is handled could be done different ways. Once the text is approved, then and only then would the system permit the files to be pushed out to mirrors, and once the files are pushed, the system would automatically send out the advisory text. This theoretical system should also have a mechanism in place to be able to handle embargoed security items, so that the errata process can be started early, and a date entered into the tool which prevents public release of the packages until the embargo date is reached. This automates prevention of accidental early disclosure of security issues rather than relying on humans to not make mistakes. Call me crazy, I don't know where I managed to get all these ideas from, but it all just came together in my mind somehow.[1] Now that there is at least one theoretical solution to the problem, if this solution were to be considered, we need the following: 1) Someone to design the detailed solution 2) Someone to implement the design and test it 3) Put the new system in place and start using it. In #1 and #2 above, "someone" could be either a Red Hat employee voluntarily taking on the task on their personal time, or it could be a Red Hat employee taking on the task under work time, or it could be a person in the community taking on the task. My personal thought, is that it wont happen by a Red Hat employee under company time, unless it is designated as a high priority task that needs to be addressed right away, which for better or worse, I don't think is the case right now. It could happen by a Red Hat employee on their own time, if someone is enthusiastic about it enough and has the personal time to spare, however I think if anyone had the time and was enthusiastic about it enough, that it would have been done by now. It's much easier to just keep using the existing manual system than to spend a few weeks manpower in one's personal time to do it. Doesn't really sound like a "fun" project to me that we're likely to see one scratch one's personal itch per se. My thought is that the only way we'll ever see a new fedora errata infrastructure come into existance, is if Red Hat decides it is high priority enough to allocate developer resources to solving the problem internally, or alternatively if someone in the community got highly motivated to design something and hack on it along with some input/advice from Red Hatters. Now that I've expressed my thoughts out loud, before anyone steps up to say "Ok Mike, great idea, now send us your patches and code to do this." (which tends to be a frequent common response when one suggests ideas about a solution to a problem), I'll be the first to admit I'm not personally interested in spending time coding the solution to this problem on or off company time. I suspect everyone feels the same or we'd have something by now perhaps. Nonetheless, I do put forth my opinions above on how this could be solved, in hopes that someone who does have a direct personal interest and the time to devote to the task, might find the motivation to take up the project and perhaps we'll end up with something to try out in the future. Until then, IMHO, there's a high likelyhood that Fedora updates will more or less continue to be inconsistently released in a fairly ad hoc manner. Remove humans from the process as much as possible, making computers do the work, and the problem mostly solves itself. TTYL