On Mon, 29 Nov 2004 12:43:15 +0100, Bernd Bartmann
As such script doesn't seem to exist yet what do think of just
something like the tracker bug for FC3 where we add all the missing
update announcements. This means adding a separate bug to each package
without update announcement and using this as an blocker for the tracker
bug. If this looks ok to you I can volunteer and add these bugs.
Getting individual bug reports against each component is the goal...
but security issues
makes the use of a tracking bug tricky. There will be circumstances
that will require bugs to be marked as private. Having a tracking bug
for missing annoucements could very well mean the tracking bug itself
will have to be marked private....defeating the point of the trackiing
bug. Individual bug reports to components, aren't as tricky... the
package maintainer can mark individual reports as private if need be
without impacting other components.
Also I think there should be a central instance (person) that sends
all update announcement. Another thing that I already suggested over a
year ago is that all announcements should be GPG signed using a global
Fedora or Red Hat key.
This requires automation in the build process and how maintainers
interact with the build system and how you define a build master
individual or automated signing. I think there has been great
reluctance to work on this part of the build system until after Fedora
Extras officially launches.. in order to prevent having to redo this
again once contributor updates start flowing. I'm pretty sure other
people recognize something along these lines has to be done.. but the
focus has been on getting the build system opened up for non Red Hat
contributors. Once this happens... I hope internal efforts can be
refocused on identifying several rougher aspects of the red hat and
contributor build process including annoucement generation that need
some automation love.
I personally see the only garunteed solution for annoucements is to
demand annoucement text be in the system when a package maintain
submits a build to be an update. And such an annoucement requirement
will have to be flexible enough to take into account security embargos
so that an annoucement text can be requested to show up on a certain
date...after the package is in the update tree if need be. This is
the only way to prevent packagers from forgetting about annoucement
text generation. Right now, its not so tough to find a red hat
employee to beat up on another red hat employee if you have access to
any red hat people on a daily basis. But in the future... for fedora
extras.. its going to be much harder to get access to far flung
contributors who are using the same build process as Core maintainers.
And i think people realize the problem exists and I hope they realize
it will get worse once contributors can start spinning up packages
into extras from the same build system. But any real process solution,
is going to have to fit inside the details of the contributor build
process.. which isn't finalized. Its just one of those situations
where the problem is obvious, and the potential solution space is
very wide.. but all specific constraints aren't in place yet to build
a workable implementation that fits the larger process.