On Fri, May 19, 2006 at 04:32:25PM -0400, Josh Bressers wrote:
> In Legacy we use the bugzilla number as the update ID. I'm not entirely
> sure how Fedora does it. I think it may come from the update tool, and
> if/when we move the update tool to be external and work for all Fedora
> stuff then it would be easy to have uniques.
I was thinking about this just the other day. There are two things that
could work I think. The first is to use the bugzilla ID. This has the
advantage of being unique and easy, but has the disadvantage of being a
seemingly random number.
What about multiple bugs per update ?
The second idea is how we did Core updates long long ago (well sort
The way Core updates were done long ago was a problem, and it has been
fixed via the update system.
We put a file in our cvs repository that looks a bit like this
<see if you can figure out what's next>
We then take one
2006-001 some package
and commit the file. It's important we remember to commit the file lest
someone else steal it. It prevents concurrency issues as only one person
can commit at a time.
Ideally I think it would be best to have a directory layout as such
We could then write a script that we run with a package name. It then
modifies the ids file, adds a new skeleton file in text/ then runs
cvs commit -m 'Create errata 2006-001'
Once we're happy with the errata text (multiple people can read/modify it),
we run another command that magically mails it to the list in question, and
makes a note in the ids file that it's been "pushed" along with the date.
This would allow us to work on advisories before the packages are ready.
We could also then generate a sort of advisory index page for the project
so when we find some web space somewhere, publishing our advisories is
If we ensure we note the bugs fixed in our errata it will also be possible
to close the bugs automagically via our script.
The current update system already automatically generates and sends
advisory text, as well as automatic bug commenting/closing.
Seeing as how getting the update system out from under it's rock is
getting to be a pretty large priority, I'd hate to have us duplicate
this functionality for Extras/Legacy/Core.
Ideally, it would be nice to have a single system which can be used to
push core/extras/legacy updates and give us the ability to generate
project-wide statistics, and automate mailing list and bugzilla
I jotted down some notes a while back on making the current update
system more modular to be able to extend legacy and extras, but due to
classes/finals have been unable to implement it. Thoughts?