Updated co-maintainership proposal -- guidelines

[Thorsten Leemhuis]

Thorsten Leemhuis schrieb:
> On 14.02.2007 23:06, Brian Pepple wrote:
>> /topic FESCO-Meeting -- Encourage co-maintainership -- all, thl
> FYI, I reworked the last proposal and some FESCo members looked over it 
> and seemed to agree with it so far, too. See
> http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership
> for details. Please comment.

As announced in the other mail here are the guidelines up for discussion.

----

== Guidelines ==

The following sections up until the end of this document describe some
guidelines how co-maintainership should be used in practice. Note that
this section is entitled "guidelines", and not "rules". In other words:
you don't have to follow the guidelines if there is a good reasons to.
But please keep in mind that they were carefully written and that some
parts of it take the interest of the project as a whole into account, to
make sure Fedora stays healthy and grows up -- that might not be obvious
on the first sight. Thanks for helping us with it.

=== How does is it supposed to work in detail ===

Something like the following points describe the concept roughly:

 * in most cases the primary maintainer is the primary per-release
maintainer for all supported distributions at the same time. There are
two co-maintainers, and the three make sure everybody knows the
important stuff and they share the load a bit, to make sure everybody
knows about the details of a package.

 * the primary maintainer should normally be the primary per-release
maintainer for the Fedora devel branch, as that's the most important one

 * all the maintainers of a particular package should be co-maintainers
or observers (somebody that gets CCed to bugs, get noticed of commits
and builds, but normally doesn't do any work) for the Fedora devel
branch, as that's where all the fun stuff happens.

 * the per-release primary maintainer takes care of the a package for
that release. He should have at least one co-maintainers for maintaining
that package in that relase

 * bugs get assigned to the primary per-release maintainer; the primary
maintainer and the co-maintainer for that release get into the CC list.
The per-release maintainer has to make sure the bugs get fixed, but of
course some of the other maintainers of that package can do that, too.

 * all the maintainers should check each others commits for correct- and
saneness.

 * the primary maintainer should make sure important bugfixes get
applied to all the supported distributions where it makes sense

 * for the devel branch: Small changes (for example: package
enhancements, bugfixes) and medium sized changes (for example: update
from 1.0.1 to 1.0.2) go directly to cvs and get build. If someone feels
unsure about a commit he should wait one or two days before actually
building or pushing the package out to the repos, as that should give
the other maintainers a chance to yell if they see problems. Big changes
(for example: update from 1.0.1 to 1.2.0 or heavy changes in the spec
file) should normally get coordinated between the different maintainers;
a temporary separate branch in the cvs can be used for this purpose as
well as of course e-mail or bugzilla.

 * for released distributions: Small changes (for example: package
enhancements, bugfixes) get go directly to cvs. The other maintainers of
that package should have the chance (e.g. a short time period, like two
days) where they can commit other enhancements (to save users lots of
upgrades) or to discuss the committed change before its actually pushed
to the users. With the current (FC7T1) scheme it means: don't build the
package immediately, in the future with the new repo push stuff from
lmacken it hopefully should be easily possible to define a waiting
period in updates-testing before a package gets pushed out to the proper
repo. Only the per-distribution maintainer should commit and build
medium sized changes, that of course should have seen testing in devel
first; co-maintainer of course should have a chance to comment on the
commits before the package gets to the repo. Big changes get coordinated.

 * the usual rules for
[:Extras/Policy/WhoIsAllowedToModifyWhichPackages: modifying other
people packages] remain intact, thus people from QA, Security or
Arch-SIGs might touch the package, too. There is the strong wish to have
a group of long-term contributors (say FESCo members, Release-Managers,
Sponsors and some other hand-selected people) that get access everywhere
to commit package updates easily without asking the maintainers, in case
the maintainers are not fixing stuff or if the changes are small and
obvious (it's often a lot easier to commit a simple spec files touch
than to create a patch, send it to the maintainer or open bugzilla).

 * the primary maintainer has to approve new co-maintainers. He now and
then should search for co-maintainers if there aren't enough.

=== Coordination between maintainers ===

The primary maintainer can set individual guidelines what his
co-maintainers are allowed and what not; be has to put them into a file
"""rules""" in the packages top level directory of the version control
system (e.g. packagename/rules). Those rules are optional and should
only be set in place if there is a strong need to (we don#t want
different rules for each package, as that will result in a major pita).
When you do so please keep the goals of the project as a whole in mind
-- the Fedora Distribution in a big *community* project and keeping
something like that running is not much helped with a "This is my
package, I don't want other people touching it" attitude.

=== Disputes ===

We had some conflicts in the past between the package maintainers and
users or other contributors how to best maintain a package. Similar
conflicts will arise if two or more people work together on a package
(a: "1+1=2"; b: "no, you're stupid; 1+1=0x0000010"; c: "you are both
stupid, 1+1=11"). Most of them will probably be solved without much
noise, but some need a bit help. There are no hard rules how those
disagreements shall be solved, but here are some suggestions how it
could be solved:

 * if two maintainers are in disagreement over a detail ask the third
maintainer

 * if no consensus can be found ask on the appropriate mailing list

 * if still no consensus can be found ask a FESCo member to mediate

If co-maintainers get the impression that the primary maintainer is a
lame duck and doesn't do his job properly then they should kindly ask
the primary maintainer to hand over the package. If he's unwilling for
no good reasons or does not respond at all or seems to be AWOL then
again a mediator has to be found. FESCo can hand over a package to
somebody else if there is a strong need to (packager does not
respond/AWOL/is unwilling to find compromisses on issues) if the
committee believes that the co-maintainers will do the job better
(should not happen often).

=== Don't (co-)maintain too many packages ===

There is a lot of work to do in Fedora and we should try to get many
contributors into the project as that should help getting the work done,
the load shared and Fedora improved. Packaging is currently the most
important (maybe even nearly the only) enter path to get involved in the
Fedora Distribution as people by doing packaging can show their
knowledge and their abilities before they get access to the more serious
stuff and respected by the key people.

If you showed that ability and gained respect by properly maintaining a
lot of packages it might be time to slowly move on to more serious
stuff. One needs time for that, and to get that it might be a good idea
to hand over some packages to other interested contributors that are
still on their way up -- that often can easily be achieved by educating
co-maintainers over time and handing over packager to them when they
have shown to be doing a good job. That should help new contributors
finding their way into the project and growing up. And it should share
the load between the different contributors with even could lead to a
better overall package quality. All that serves the Project as a whole
and improves it.

This enter path might to a wide area obsolete the old sponsor process.
Even in the linux and open source world the number of software packages
that's worth shipping in a repo is finite. We come closer to a point
where nearly all of the interesting stuff is packaged, and thus the
situations comes up (or properly came up already, but we didn't notice
it) that new contributors do not find something they actually use (we
don't want new contributors to package stuff they are not interested in,
just to get involved) that is not yet packaged. By giving those users a
chance to get involved by starting as from a non-official co-maintainer
(e.g. a observers that provides patches), over to official
co-maintainership to a real primary (per-release) maintainer we give
people a chance to become involved without stating with a package that
gets reviewed.

=== Other aspects of co-maintainership ===

We had some situations where maintainers had to stop maintaining
packages in Fedora. That can happen due to different circumstances --
sicknesses, accidents, changes in the job or at home are only some
examples for reasons to stop. Some of those situations happen suddenly
and are not foreseeable. Due to this maintainers are strongly advised to
build a healthy maintainer community around all of their packages so
those people can take over the packages smoothly even if you stop
maintaining packages tomorrow suddenly because you won in the lottery
and became millionaire.

SIGs can't become co-maintainers. Rather they should observe the
packages or make sure that the SIG members are co-maintainers everywhere
where needed. That -- if properly used -- is nearly the same as having a
SIG that co-maintains and avoids that new SIG members suddenly get
access to a lot of packages just by joining a SIG.

The jobs of the primary maintainer an the primary per-release maintainer
are there to make sure that there is someone that actually is
responsible -- that quite important, because letting a group of people
handle a package could lead to situations where nobody is actually doing
the work, because everyone thinks that one of the other maintainers will
do the work.

Nobody can be forced to maintain packages, so sometimes it might happen
that a package has only one maintainer -- that's fine, but the
maintainer should now and then ask other contributors or interested
users to become co-maintainers. We probably should automatically send
out a list of packages with only one or two maintainers now and then, so
new contributors that want to get involved more can easily find places
where help is needed. Especially packages with large numbers of open
bugs will want to find more co-maintainers to try and help solve them.

Ask upstream developers to become co-maintainer or a observer of the
package -- that could be of benefit for both sides. Having upstream
developers as a primary maintainers is often better avoided (but is
allowed) -- the goals of upstream and Fedora might be to different
sometimes (freezes or Fedora-specific stuff are some reasons, that
contributors that maybe don't really use Fedora on their machines are
not aware off) which can lead to interest conflicts.

=== Intermediate solution ===

We require the PackageDB and some other technical things to really make
above policy possible. Until we have those it works like this:

 * the general and primary-maintainers for each release are always
identical (exception: EPEL); it's the one that listed as first in
owners.list

 * co-maintainers all get listed in the last field in owners.list.
Note: currently owners.list is locked-down so changes need to be
requested through the wiki, but once the package database is live this
limitation should be removed.

 * Ideally, all packages should have at least two co-maintainers

 * make sure the packaging database has everything we need

 * make sure it is possible that people get access to version control
system, but not access to the buildsystem -- new co-maintainers that are
not properly sponsert thus can try in cvs, without doing harm

----

Comments?

CU
thl