On Mon, 05 May 2008 21:01:35 -0400
bpepple(a)fedoraproject.org (Brian Pepple) wrote:
I'm looking for some feedback on what I've got so far for the
Maintainer Responsibility Policy.
== 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.
=== Manage security issues ===
* Package maintainer should handle security issues quickly, and
if they need help they should contact the Security Response Team.
=== Deal with reported bugs in a timely manner ====
* 'Nuff said.
I think this needs expanding...
I would add:
"If you find yourself unable to handle the load of bugs from your
package(s), please ask for assistance on the fedora-devel and/or
fedora-test lists. Teaching triagers about how to triage your bugs or
getting help from other maintainers can not only reduce your load, but
improve Fedora. Consider reaching out for some (more) co-maintainers
to assist as well".
=== 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.
I would add additionally:
"Maintainers should not push every single upstream update to all
branches. Examine the changes in each upstream release and ask if the
update is worth download and update time for many users. For upstreams
that update very often with many small updates, consider waiting and
updated only when the amount of changes is worth updating.
=== 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.
Bodhi should prevent this in released branches now... so might need a
bit of re-wording.
=== 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
* Nature of the change.
* Branches (devel, F9, etc.) which will be affected by
* 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.
Might be worth mentioning the gcc and/or perl updates...
where they were done entirely in another tag and fixes were made until
the landing of the updates were pretty painless overall.
=== Miscellaneous Items ===
* Maintainers need to maintain an upgrade path for their
* 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
Looks like a good start... ;)
Thanks for looking at this.