Policy for encouraging comaintainers of packages

Digest

All packages in Fedora should normally be maintained by a group of maintainers. Ideally, each package normally should have at least three maintainers in total. There is one primary maintainer and a primary maintainer per distribution release (both often will be identical); each distribution maintainer should have at least one co-maintainer per release, to make sure there are actually at least two people for a package per each supported release. Maintainers should work towards getting at least one co-maintainer.

One important goal of co-maintainership in Fedora is to help getting new people involved into the project, while the experienced and respected maintainers get a chance to get involved with the often more complicated and more important parts of the project if they want to.

Policy

All packages in Fedora shall normally be maintained by a group of maintainers. The most important reasons for it: One maintainer can commit fixes like patches or new upstream releases that fix important bugs (for example security data-corruption issues or packaging bugs that confuse the users systems) even when the other maintainer(s) are away from keyboard due to traveling, sleeping or whatever. Maintainers further can help, guide and watch each other, which should lead to a better overall package quality.

The goal is to have at least three maintainers per package in total and at least two per supported distribution release. Big and important packages should have more maintainers -- there is no upper limit. There is a primary maintainer who takes care of the package in general; it's his job to approve and find new maintainers and to make sure their efforts get coordinated -- especially between different branches like EPEL and Fedora. Then there is a primary maintainer per distribution release -- that's often the same as the primary maintainer; bugs get assigned to the per distribution maintainer, who is in charge of the package. It does not mean that he has to do all the work, but he has to make sure the work gets done!

The maintainers should actively work towards getting at least one co-maintainer and also try to get the seconds one -- for now that means ask around one the mailing list now and then for people that might be interested in the job. The goal is to have that process mostly automated -- e.g. let a script parse the owner informations and send out mail to a mailing list now and then that contains a list of the packages that do not have enough co-maintainers yet.

The primary maintainer can't block co-maintainers for distributions he does not want to support on that basis alone -- e.g. if he does not want to care about his package in EPEL he has to accept somebody else takes care of the package in EPEL.

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 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 release.

• 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 correctness and sanity.

• 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 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 non-responsive 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/is unwilling to find compromises 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 starting 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.

Proven Packagers

Some subset of Fedora package maintainers are in a "Proven" packager group, that has the ability to make changes to most packages in the distribution. These Proven packagers may make changes to your package when the need arises. Nothing about the proven packager group should prevent you from having co-maintainers maintain your packages.

Current solution

The above policy should be followed now, as the infrastructure for it should be pretty much in place.

• the general and primary-maintainers for each release are typically identical (exception: EPEL); it's the one that listed as the devel branch maintainer in the packagedb.

• co-maintainers typically have all the same privileges as the primary maintainer, but may only have them on their own specific branch.

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

• The package database should contain all the info about maintainers and co-maintainers for each package.

• co-maintainers should have permissions to build and push updates as the maintainer does.

Procedure

The procedure is described here.