Maintainer Responsibility Policy

Xavier Lamien laxathom at fedoraproject.org
Tue May 6 13:10:49 UTC 2008


2008/5/6 Brian Pepple <bpepple at fedoraproject.org>:

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


I think you should also mention the act of "pushing to testing" repo for
each current fedora release.



> ---
>
> Thanks,
> /B
> --
> Brian Pepple <bpepple at fedoraproject.org>
>
> http://fedoraproject.org/wiki/BrianPepple
> gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
> BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080506/43279797/attachment.htm>


More information about the fedora-devel-list mailing list