Maintainer Responsibility Policy

[Kevin Fenzi]

On Mon, 05 May 2008 21:01:35 -0400
bpepple at fedoraproject.org (Brian Pepple) wrote:

> Hi all,
> 
> I'm looking for some feedback on what I've got so far for the
> Maintainer Responsibility Policy.
> 
> http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
> 
> --
> 
> == Maintainer Responsibility Policy ==
> === How long to maintain? ===
> 13 months from initial release. 
> 
> === 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. 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 think this needs expanding... 

I would add: 

"If you find yourself unable to handle the load of bugs from your
package(s), please ask for assistance on the fedora-devel and/or
fedora-test lists. Teaching triagers about how to triage your bugs or
getting help from other maintainers can not only reduce your load, but
improve Fedora. Consider reaching out for some (more) co-maintainers
to assist as well". 

> === 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. 

I would add additionally: 

"Maintainers should not push every single upstream update to all
branches. Examine the changes in each upstream release and ask if the
update is worth download and update time for many users. For upstreams
that update very often with many small updates, consider waiting and
updated only when the amount of changes is worth updating. 

> === 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. 

Bodhi should prevent this in released branches now... so might need a
bit of re-wording. 

> === 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. 
>       * 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. 

Might be worth mentioning the gcc and/or perl updates... 
where they were done entirely in another tag and fixes were made until
the landing of the updates were pretty painless overall. 

> === 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).

Looks like a good start... ;) 

> Thanks,

Thanks for looking at this. 

> /B

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080505/27e1bd20/attachment.sig>