Re: Maintainer Responsibility Policy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





2008/5/6 Brian Pepple <bpepple@xxxxxxxxxxxxxxxxx>:
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@xxxxxxxxxxxxxxxxx>

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@xxxxxxxxxx
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
-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux