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 out. > === 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 autosubscribing) > 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. 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 help. > === 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. Shouldn't there be an --all there, as well as looking at what packages BuildRequire yours? > * 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). -- Jesse Keating Fedora -- Freedom² is a feature!
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
