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