Missing update announcements

Mike A. Harris mharris at www.linux.org.uk
Fri May 6 05:50:50 UTC 2005


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




More information about the fedora-devel-list mailing list