<div class="gmail_quote">2008/5/6 Brian Pepple <<a href="mailto:bpepple@fedoraproject.org">bpepple@fedoraproject.org</a>>: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi all, I'm looking for some feedback on what I've got so far for the Maintainer Responsibility Policy. <a href="http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy" target="_blank">http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy</a> -- == 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. * <a href="http://www.redhat.com/mailman/listinfo/fedora-devel-announce" target="_blank">http://www.redhat.com/mailman/listinfo/fedora-devel-announce</a> * <a href="http://www.redhat.com/mailman/listinfo/fedora-devel-list" target="_blank">http://www.redhat.com/mailman/listinfo/fedora-devel-list</a> === Manage security issues === * Package maintainer should handle security issues quickly, and if they need help they should contact the Security Response Team. * <a href="http://fedoraproject.org/wiki/Security/ResponseTeam" target="_blank">http://fedoraproject.org/wiki/Security/ResponseTeam</a> === 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).</blockquote><div> I think you should also mention the act of "pushing to testing" repo for each current fedora release. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> --- Thanks, /B -- Brian Pepple <<a href="mailto:bpepple@fedoraproject.org">bpepple@fedoraproject.org</a>> <a href="http://fedoraproject.org/wiki/BrianPepple" target="_blank">http://fedoraproject.org/wiki/BrianPepple</a> gpg --keyserver <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a> --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -- fedora-devel-list mailing list <a href="mailto:fedora-devel-list@redhat.com">fedora-devel-list@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/fedora-devel-list" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-devel-list</a> </blockquote></div> -- Xavier.t Lamien -- <a href="http://fedoraproject.org/wiki/XavierLamien">http://fedoraproject.org/wiki/XavierLamien</a> GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB