On Mon, 2008-05-05 at 21:01 -0400, Brian Pepple wrote:
== Maintainer Responsibility Policy ==
=== How long to maintain? ===
13 months from initial release.
From initial Fedora release right? If you bring a package in around F10
Beta, you're expected to stick around for 13 months after F10 final goes
=== 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.
Do we have this hooked up now, or is that a future item (the
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
=== 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 would note here that putting a comment in the bug letting folks know
when you're going to be too busy to look at the bug immediately would
=== 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
* Nature of the change.
* Branches (devel, F9, etc.) which will be affected by the
* 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.
Shouldn't there be an --all there, as well as looking at what packages
* If your package upgrade breaks other packages in Rawhide,
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
* 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
Fedora -- Freedom² is a feature!