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