Maintainer Responsibility Policy
Jesse Keating
jkeating at redhat.com
Tue May 6 01:25:11 UTC 2008
On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote:
> == Maintainer Responsibility Policy ==
> === How long to maintain? ===
> 13 months from initial release.
From initial Fedora release right? If you bring a package in around F10
Beta, you're expected to stick around for 13 months after F10 final goes
out.
> === Belong to the appropriate low-traffic mailing list ===
> * Package maintainers will receive important announcements through
> the moderated fedora-devel-announce mailing list. Maintainers
> will be automatically subscribed to this list.
Do we have this hooked up now, or is that a future item (the
autosubscribing)
> Everyone that is
> a primary maintainer of a package in Fedora is also strongly
> encouraged to subscribe to the fedora-devel list, though this is
> not mandatory.
> * http://www.redhat.com/mailman/listinfo/fedora-devel-announce
> * http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
> === Manage security issues ===
> * Package maintainer should handle security issues quickly, and if
> they need help they should contact the Security Response Team.
> * http://fedoraproject.org/wiki/Security/ResponseTeam
>
> === Deal with reported bugs in a timely manner ====
> * 'Nuff said.
I would note here that putting a comment in the bug letting folks know
when you're going to be too busy to look at the bug immediately would
help.
> === Maintain stability for users ===
> * Package maintainers should limit updates within a single Fedora
> release to those which do not require special user action. Many
> users update automatically, and if their applications stop
> working from no action of their own then they will be upset.
> This goes doubly for services which may break overnight.
>
> === Track dependency issues in a timely manner ===
> * In the development tree, and to a small degree in the release
> trees as well, updates to packages may cause other packages to
> have broken dependencies. Maintainers will be alerted when this
> happens, and should work to rebuild their packages with all due
> haste. Broken dependencies may leave end user systems in a state
> where no updates will be applied. In order to keep the
> distribution in a reasonable state, someone will step in and
> rebuild packages that have had dependency issues for some time,
> but package maintainers should not rely on these rebuilds.
>
> === Notify others of changes that may affect their packages ===
> * Some packages are depended upon by others; in this case, changes
> to one package may cause issues for others. Maintainers should
> be aware of the effects that changes to their packages may have,
> and should alert to the fedora-devel-announce mailing list of
> updates which contain ABI or API changes which may cause
> dependency problems for other packages. The announcement should
> occur a week before the packages update, so all maintainers
> affected are notified. The announcement should include the
> following information:
> * Nature of the change.
> * Branches (devel, F9, etc.) which will be affected by the
> change.
> * Expected date of the change.
> * List of packages which are affected by the change.
> Generally, this is merely the list of packages which
> depend directly on the package which is being updated,
> and can be found with "repoquery --whatrequires package"
> where "package" is the package being updated.
Shouldn't there be an --all there, as well as looking at what packages
BuildRequire yours?
> * If your package upgrade breaks other packages in Rawhide, you
> should try to help fix the packages affected. For example, when
> Python-2.5 was integrated into Rawhide, Jeremy Katz at least
> fixed the important packages and queued a rebuild for all the
> other packages affected.
>
> === Miscellaneous Items ===
> * Maintainers need to maintain an upgrade path for their
> packages.
> * F(current-1) -> F(current) -> Rawhide
> * Packages should be pushed to the Rawhide branch first. If it
> builds and works fine for a few days, then it can be pushed to
> F(current). If there is a good reason to push it to
> F(current-1), it should be done after a few days of being in
> F(current).
--
Jesse Keating
Fedora -- Freedom² is a feature!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080505/e093f47d/attachment.sig>
More information about the fedora-devel-list
mailing list