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