Maintainer Responsibilities

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060826/17a6de70/attachment.sig>