On Thu, 2008-12-11 at 08:35 +0100, Kevin Kofler wrote:
> Well, I agree with you on this point:
> * Updates should contain a description of:
> - what's new (a link to the upstream changelog will do, or the maintainer
> can sum up the changes him/herself) and
> - where not immediately obvious ("This bugfix release was pushed to fix the
> bugs in the previous release.", duh), why the update is being pushed
> (e.g. "new version of libfoo needed for the latest bugfix version of bar").
> * If the update fixes a bug filed in Fedora, the Bugzilla reference should
> be present.
> * Non-critical, non-trivial updates (and in most cases version upgrades are
> neither critical nor trivial, but there are exceptions) should stay in
> updates-testing for at least a week.
These are a pretty reasonable start to a set of guidelines to help users
determine when and what to push as updates.
Kevin, you seem to have a pretty strong stake in this discussion,
perhaps you and I and any others that are interested can get together on
IRC and try to hash out a set of guidelines like the above to put in a
wiki place somewhere that new (and existing) contributors can reference
when deciding if they should do an update or not?
I think one of the big problems we have is new maintainer training, and
lack of guidelines like the above. We just expect them to "figure it
out" and we shouldn't be surprised when something goes wrong.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
