The draft document tibbs wrote up for Package Maintainer Responsiblities has been moved into the official Fedora Extras space: http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy This is an important issue that needs input so let's take a look: > Responsibilities of maintainers of packages in Fedora Extras: These responsibilities live in a comaintainer-enabled world. So we need to be a bit more specific about which maintainers we're talking about. I see two possiblities: 1) Maintainers means the primary maintainer. Usually the person who created the initial package and guided it through review. Everything within this policy is then the responsibility of the primary maintainer. Comaintainers can do two things for a package: A) Help the primary maintainer in these duties B) Do things not designated to the primary maintainer by this policy 2) Maintainers means all maintainers of the package, primary and co-maintainers (if any). I am going to work with the first definition because it seems to be what most of us have been using in the past. It also allows us to clearly specify what our expectations are for a package within Extras. > * How long to maintain? > * Proposal: All releases until Legacy drops maintenance. (Currently > includes FE3, 4, 5 and devel but soon will be 3, 4, 5, 6 and devel.) > || Many people don't believe they signed up to maintain something > across five different releases. Rules about stability bring up > difficult issues like the necessity of backporting fixes and such. || I agree with the Con side here. Nicholas Mailhot has been involved in several mailing list threads on this issue and has given very coherent arguments against this. I would just add that there are two different philosophies for packaging between the active releases and the maintenance releases. Active releases are much more geared towards upgrades and enhancements. Maintenance releases are focused on security and major bugfixes. Maintainers that want to play with the latest software are going to fit in with the devel tree and current release. Maintainers that want to have a longer term, stable platform to base their servers on are going to be more in tune with the Maintenance Release Philosophy. > * Proposal: All releases until the release goes to legacy. (Currently > includes FE5 and devel, but soon will be 5, 6 and devel.) > || Legacy isn't equipped to maintain Extras packages and neither is > the security team. We can't just leave the packages unmaintained. || This proposal will split the responsibility for maintaining along the natural boundary where only important issues are fixed versus where new features are encouraged. What happens to packages on the maintenance side of this split is the big question. I think we need to aim to use the comaintainer mechanism to manage those releases but have a Maintenance SIG that helps coordinate it, at least for the short term. Basically, a maintainer or comaintainer will need to commit to maintaining one or more older releases that are still in Legacy or the package will be considered orphaned for those releases. The SIG exists to coordinate getting people interested in working on Legacy Releases together with packages that would otherwise be orphaned. > * Manage security issues quickly. (For how many releases?) (This > ties into the security policy.) > * Deal with reported bugs in a timely manner. (This ties in with the > orphaned package policy.) As long as the number of releases is taken care of above, these should be simple tie ins to the security, AWOL, and orphaned packages policies. Having links to the relevant sections would be good for the final draft. > * Maintain stability for users; don't issue incompatible updates > needlessly in stable releases. (This ties in with the incompatible > package policy which hasn't been completed.) > * Proposal: 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. Questions: * Is it okay if the package changes file formats but the end-user can run a converter to restore their settings/data afterwards? * What happens if not upgrading a package blocks several other packages that wouldn't be considered "incompatible"? * Which policy wins in the case of a security flaw vs a compatibility problem? * Do we worry about third party repositories or only Fedora repositories? * What happens if there are "showstopper" bugs on some architectures or for some people and an incompatible upgrade will fix them? Is this a maintainer responsibility or a guideline for when (not) to update packages in Extras? Maybe it shouldn't be mentioned on Maintainers Responsibilities or should just be a link (like Security, AWOL, and orphaned policies)? -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
