<br><br><div class="gmail_quote">2008/5/6 Brian Pepple <<a href="mailto:bpepple@fedoraproject.org">bpepple@fedoraproject.org</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<br>
I'm looking for some feedback on what I've got so far for the Maintainer<br>
Responsibility Policy.<br>
<br>
<a href="http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy" target="_blank">http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy</a><br>
<br>
--<br>
<br>
== Maintainer Responsibility Policy ==<br>
=== How long to maintain? ===<br>
13 months from initial release.<br>
<br>
=== Belong to the appropriate low-traffic mailing list ===<br>
* Package maintainers will receive important announcements through<br>
the moderated fedora-devel-announce mailing list. Maintainers<br>
will be automatically subscribed to this list. Everyone that is<br>
a primary maintainer of a package in Fedora is also strongly<br>
encouraged to subscribe to the fedora-devel list, though this is<br>
not mandatory.<br>
* <a href="http://www.redhat.com/mailman/listinfo/fedora-devel-announce" target="_blank">http://www.redhat.com/mailman/listinfo/fedora-devel-announce</a><br>
* <a href="http://www.redhat.com/mailman/listinfo/fedora-devel-list" target="_blank">http://www.redhat.com/mailman/listinfo/fedora-devel-list</a><br>
<br>
=== Manage security issues ===<br>
* Package maintainer should handle security issues quickly, and if<br>
they need help they should contact the Security Response Team.<br>
* <a href="http://fedoraproject.org/wiki/Security/ResponseTeam" target="_blank">http://fedoraproject.org/wiki/Security/ResponseTeam</a><br>
<br>
=== Deal with reported bugs in a timely manner ====<br>
* 'Nuff said.<br>
<br>
=== Maintain stability for users ===<br>
* Package maintainers should limit updates within a single Fedora<br>
release to those which do not require special user action. Many<br>
users update automatically, and if their applications stop<br>
working from no action of their own then they will be upset.<br>
This goes doubly for services which may break overnight.<br>
<br>
=== Track dependency issues in a timely manner ===<br>
* In the development tree, and to a small degree in the release<br>
trees as well, updates to packages may cause other packages to<br>
have broken dependencies. Maintainers will be alerted when this<br>
happens, and should work to rebuild their packages with all due<br>
haste. Broken dependencies may leave end user systems in a state<br>
where no updates will be applied. In order to keep the<br>
distribution in a reasonable state, someone will step in and<br>
rebuild packages that have had dependency issues for some time,<br>
but package maintainers should not rely on these rebuilds.<br>
<br>
=== Notify others of changes that may affect their packages ===<br>
* Some packages are depended upon by others; in this case, changes<br>
to one package may cause issues for others. Maintainers should<br>
be aware of the effects that changes to their packages may have,<br>
and should alert to the fedora-devel-announce mailing list of<br>
updates which contain ABI or API changes which may cause<br>
dependency problems for other packages. The announcement should<br>
occur a week before the packages update, so all maintainers<br>
affected are notified. The announcement should include the<br>
following information:<br>
* Nature of the change.<br>
* Branches (devel, F9, etc.) which will be affected by the<br>
change.<br>
* Expected date of the change.<br>
* List of packages which are affected by the change.<br>
Generally, this is merely the list of packages which<br>
depend directly on the package which is being updated,<br>
and can be found with "repoquery --whatrequires package"<br>
where "package" is the package being updated.<br>
* If your package upgrade breaks other packages in Rawhide, you<br>
should try to help fix the packages affected. For example, when<br>
Python-2.5 was integrated into Rawhide, Jeremy Katz at least<br>
fixed the important packages and queued a rebuild for all the<br>
other packages affected.<br>
<br>
=== Miscellaneous Items ===<br>
* Maintainers need to maintain an upgrade path for their<br>
packages.<br>
* F(current-1) -> F(current) -> Rawhide<br>
* Packages should be pushed to the Rawhide branch first. If it<br>
builds and works fine for a few days, then it can be pushed to<br>
F(current). If there is a good reason to push it to<br>
F(current-1), it should be done after a few days of being in<br>
F(current).</blockquote><div><br>I think you should also mention the act of "pushing to testing" repo for each current fedora release.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
---<br>
<br>
Thanks,<br>
/B<br>
<font color="#888888">--<br>
Brian Pepple <<a href="mailto:bpepple@fedoraproject.org">bpepple@fedoraproject.org</a>><br>
<br>
<a href="http://fedoraproject.org/wiki/BrianPepple" target="_blank">http://fedoraproject.org/wiki/BrianPepple</a><br>
gpg --keyserver <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a> --recv-keys 810CC15E<br>
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E<br>
</font><br>--<br>
fedora-devel-list mailing list<br>
<a href="mailto:fedora-devel-list@redhat.com">fedora-devel-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/fedora-devel-list" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-devel-list</a><br></blockquote></div><br><br clear="all"><br>-- <br>Xavier.t Lamien<br>--<br>
<a href="http://fedoraproject.org/wiki/XavierLamien">http://fedoraproject.org/wiki/XavierLamien</a><br>GPG-Key ID: F3903DEB<br>Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB