Hi all! Fedora Extras for a long time wanted to have more than one maintainer per package as that has several advantages (see below). But until now we never had a policy how it should look like and how it those maintainers should work and interact. I took some time and wrote something up. Please comment! CU thl P.S.: This stuff (and some more details) can be found in the wiki at http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership === Why do we need it === There are several reasons why we need it: * co-maintainership could be the main new enter path for new Extras contributors -- people could start their "Extras maintainer life" with co-maintaining packages when they don't know what to package (a lot of/most interesting stuff is already packaged so the traditional enter path Fedora Extras used in the past doesn't scale anymore). Experienced maintainer could then watch, help and teach the new contributor that way. If the new contributor showed that he understands everything well he gets more permissions in Extras -- he for example could take over a package as primary maintainer * upstream maintainers could co-maintain their packages. They could import the updates while the fedora-maintainers watches their doings and checks that everything stays compatible to Fedora and the Fedora packaging guidelines * One maintainer does not scale; for example, if a maintainer offline due to vacations, traveling to conferences or other happenings someone else has should be easily able to fix security stuff * people get when distracted by other projects/work areas/schedules/real life and can't watch their packages closely to fix/update stuff * people use packages sometimes differently -- one maintainer might be more interested in feature foo while the other might be more interested in bar -- let them work together and the package is better maintained and the quality improved for users that need both foo and bar * maintainers of one package could watch and check each others commits * we support multiple releases (and will probably support even more in the future) -- one packager might be interested in devel and FC-current only while another might be interested in FC-current -1, or EPEL * some people maintain more then 50 (one even more then 100) packages -- we should make sure they don't burn out. And the package quality probably is better if one maintainer only maintains a smaller number of packages * sponsors could act as primary-maintainer for a new package from a new contributor in the beginning if they are unsure if the new contributor is worth sponsoring. The new contributor could do all the work in cvs while being watched by the sponsor. Only the sponsor would have permission to request the build of a package in the beginning; the new contributors gets more permissions if everything worked fine for a while. === Policy Proposal === ---- == Digest == All packages in Fedora Extras shall normally be maintained by a group of maintainers. 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); he should have at least one co-maintainer per release. Maintainers and sponsors are encouraged to use co-maintainership to educate new contributors an help them getting involved and integrated into the Project. Maintainers should hand over packages to co-maintainers when they have lots of packages to improve the quality, share the load and get people involved. == Co-maintainership == All packages in Fedora Extras shall normally be maintained by a group of maintainers. That has several benefits; maintainers for example can watch and help each other. One maintainer further can fix important bugs (security, data-corruption, whatever!) even when the other maintainer(s) are offline (traveling, sleeping, whatever). The goal is to have at least three maintainers per package in total and at least two per distribution release. Big and important packages should have more -- there is no upper limit. There is a primary maintainer that takes care of the package in general; it's his job to make sure the efforts of the different maintainers get coordinated. Then there is a primary maintainer per distribution release (often that will be the same as the primary maintainer); bugs get assigned to him. It does not mean that he has to do all the work, but he has to make sure the work gets done! All the maintainers normally should share the load to make sure that all are familiar with the package -- the Fedora Distribution in a big community project and keeping something like that running is not be helped with a "This is my package, I don't want other people touching it" attitude. Packages primary maintained by Red Hat employees should have at least one co-maintainer from the community. They should try to hand over certain regular maintain task to the the community; that should help getting the community involved everywhere and to get some load of the Red Hat employees so they can focus on more imporant things -- that's best for both sides! Co-maintainership should also make the sponsorship process easier, too. New contributors can (they don't have to -- that's the decision of the sponsor) start as co-maintainers for the packages they submitted while the Sponsor or some experienced packager gets primary maintainer of it. The new contributor then get limited ACLs first that allow him to only modify those packages in CVS that they co-maintains. The primary maintainer can check the things that got changed before he kicks off the build. The new contributor gets full access after everything worked fine for a while. === 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 the wiki at Packages/<package-name>/MaintainerRules . A hint to that page should be as comment on the top of the spec file. Those rules are optional, it normally works like this if no rules were specified: * the per-release primary maintainer takes care of the a package for that release; he has to make sure the work gets done. He shares the workload with the co-maintainers. All of them check each others commits for correctness. * all maintainers can directly commit small changes (for example: small package enhancements/fixups) to cvs. Only the primary maintainers normally builds them. * medium sized changes (for example: update from 1.0.1 to 1.0.2) should get coordinated. Best and easiest practice it to commit changes if they are obvious and wait one or two days before building/pushing the package out to give the co-maintainers a chance to yell if they see problems. Only the primary maintainers normally builds the update. * 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 via e-mail or bugzilla before they get committed * 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. * the primary maintainer handles who is co-maintaining his packages === Disputes === There are big chances that conflicts will always arise if two or more people work together on a package (a: "1+1=2"; b: "no, you're stupid; 1+1=10"; c: "you are both stupid, 1+1=11"). There are no hard rules how maintainers should solve those disagreements. But in practice it should be something like this: * if one maintainer thinks the primary (per release) maintainer is doing something wrong then the primary (per release) maintainer should ask a third person (preferred: another maintainer of said package or the SIG that handles them) as mediator or ask on the mailing list for comments. * if two maintainers agree that the primary maintainer is doing something not as they would like to then the primary maintainer should really start thinking about changing something to make those two happy. A fourth person or a SIG can be asked as mediator; the list can be used to get further comments, too. If the problems don't get solved that way a FESCo-member should be asked 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 AFK then again a mediator has to be found. FESCo can hand over a package to somebody else if there is a need to (packager does not respond) if the committee believes that the co-maintainers will do the job better. === Don't maintain to many packages === People owning a lot of packages are encouraged to hand over maintainership to other maintainers with less packages. That should share the load between different people and result in better overall package quality, as people that maintain only a small number of packages often take more care of them than those with a lot of packages. By handling over packages to other people we let new people learn packaging and maintaining software in Fedora, too; that should help getting more people involved into Fedora and let them grow up. That serves the Project as a whole and is important for us. Maintainers with lots of packages thus should ask others (existing co-maintainers and *especially* new contributors that seems to be willing to get more involved) that seem to be interested in a package to become a co-maintainer for a package. Educate those co-maintainers a bit and tell them about the backgrounds of the package and how it was maintained in the past. Then let the co-maintainer do some work and watch him. If he does a good job give him more responsibilities over time and while stepping back from it more and more over time. At some point hand over the job as primary (release) maintainer to the co-maintainer when he did the job fine; become a co-maintainer for the package at the same time. If the new primary maintainer continues to do a good job consider stepping away completely to yet make more room for a new packager to get involved. === 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 per-se. Rather they should observe the packages or make sure that SIG members are co-maintainers. === 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 * there are no ACLs yet in the VCS, thus we need to find ways to live without them * all packages should have at least two co-maintainers -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
