2:27 p.m.
First of all, congratulations to those who made Fedora Extras Updates
announcements possible to the public for the first time!
[1] https://www.redhat.com/archives/fedora-package-announce/2006-May/msg00093...
[2] https://www.redhat.com/archives/fedora-package-announce/2006-May/msg00094...
[3] https://www.redhat.com/archives/fedora-package-announce/2006-May/msg00095...
Now, we need a public announcement regarding our new effort.
Could someone in this project make an official announcement on Fedora
Extras Updates?
This will be posted in Fedora Weekly News as well as Fedora Weekly Reports.
ps. The tag in subject in [2] should be Fedora Extras *4* update:
kphone-4.2-9.fc4
It's been corrected in Fedora News post. [4]
[4] http://fedoranews.org/cms/node/942
Regards,
--
Thomas Chung
http://fedoraproject.org/wiki/ThomasChung
3:03 p.m.
On Fri, 2006-05-19 at 12:27 -0700, Thomas Chung wrote:
First of all, congratulations to those who made Fedora Extras
Updates
announcements possible to the public for the first time!
Yep, that's nice, thanks Dennis.
Do we have templates for those announcements available somewhere? What
about update ID's, should Extras announcements get ones from the
FEDORA-* sequence or have their own or something else?
3:19 p.m.
On Fri, 2006-05-19 at 23:03 +0300, Ville Skyttä wrote:
Do we have templates for those announcements available somewhere?
What
about update ID's, should Extras announcements get ones from the
FEDORA-* sequence or have their own or something else?
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.
--
Jesse Keating
Release Engineer: Fedora
3:32 p.m.
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.
The second idea is how we did Core updates long long ago (well sort of).
We put a file in our cvs repository that looks a bit like this
2006-001
2006-002
2006-003
<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
advisories/
ids
text/
2006-001
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
trivial.
If we ensure we note the bugs fixed in our errata it will also be possible
to close the bugs automagically via our script.
Thoughts?
--
JB
4:18 p.m.
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
of).
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
2006-001
2006-002
2006-003
<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
advisories/
ids
text/
2006-001
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
trivial.
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.
Thoughts?
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
interaction.
I jotted down some notes[0] 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?
luke
[0]: http://fedoraproject.org/wiki/Infrastructure/UpdateSystem
7:43 p.m.
> We put a file in our cvs repository that looks a bit like this
>
> 2006-001
> 2006-002
> 2006-003
> <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
>
> advisories/
> ids
> text/
> 2006-001
>
> 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
> trivial.
>
> 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.
> Thoughts?
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.
I had a short chat with Luke about this yesterday. An update system is
still a few months out. Unless someone complains, I'm going to create a
simple script based system similar to what I describe above. I think we've
drug our feet long enough.
If anyone has any thoughts or complaints, let me know.
--
JB
4:03 p.m.
On Fri, May 19, 2006 at 04:19:52PM -0400, Jesse Keating wrote:
On Fri, 2006-05-19 at 23:03 +0300, Ville Skyttä wrote:
>
> Do we have templates for those announcements available somewhere?
> What
> about update ID's, should Extras announcements get ones from the
> FEDORA-* sequence or have their own or something else?
>
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.
Core update IDs are sequential, and come from the update system.
Using the bug # as the ID is probably not the best idea, since multiple
bugs can potentially be fixed by a single update.
luke
3:34 p.m.
On Friday 19 May 2006 15:03, Ville Skyttä wrote:
On Fri, 2006-05-19 at 12:27 -0700, Thomas Chung wrote:
> First of all, congratulations to those who made Fedora Extras Updates
> announcements possible to the public for the first time!
Yep, that's nice, thanks Dennis.
Do we have templates for those announcements available somewhere? What
about update ID's, should Extras announcements get ones from the
FEDORA-* sequence or have their own or something else?
I based what i sent out on a
Fedora Core announcement.
Ive had a couple of private emails about a unique ID and there is nothing
defined so I did not include one. I thought aboout perhaps a cgi script to
create the email. then it could create most of the email automatically.
with a little input from sender.
that would keep things consistent in look. ideas? there would need to be
some kind of access control. I plan on always sending announcements for
security issues with my packages. should we approach fesco asking for a
policy that security updates need announcements?
--
Dennis Gilmore, RHCE
Proud Australian
3:42 p.m.
On Fri, 2006-05-19 at 15:34 -0500, Dennis Gilmore wrote:
that would keep things consistent in look. ideas? there would need
to be
some kind of access control. I plan on always sending announcements
for
security issues with my packages. should we approach fesco asking
for a
policy that security updates need announcements?
We need to harp on luke macken to get a version of the update system
external. Then all we have to come up with is the advisory text, the
rest of the package stuff is generated automatically.
I don't think we need to go to fesco, we'll just make policy ourselves
and then maybe get fesco to rubberstamp it.
--
Jesse Keating
Release Engineer: Fedora
6525
days inactive
6550
days old
security@lists.fedoraproject.org
9 comments
6 participants
participants (6)
-
Dennis Gilmore -
Jesse Keating -
Josh Bressers -
Luke Macken -
Thomas Chung -
Ville Skyttä