From Fedora Project Wiki

< Extras‎ | Schedule

Revision as of 16:28, 24 May 2008 by Ravidiip (talk | contribs) (1 revision(s))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Owner

thl, all

Target date

Short term plans: Soon

Middle term plans: FC7T1

Why

  • 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 packages so the traditional enter path doesn#t scale anymore). Experienced maintainer could watch, help and teach the new contributor. 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 and the main fedora-maintainers watches their doings and checks that everything stays compatible to Fedora Core and the Fedora packaging guidelines
  • Someone has to fix security stuff during those time periods if a problems went public but everybody is offline now and then for some time, take for example vacations or traveling to conferences. I suspect that a lot of contributors probably are far away from a computer at least once a year for for one, two, three, four or even more weeks -- co-maintainers could fix stuff in those timeframes.
  • 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
  • all 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 -2, but has no interest in FC-current or devel
  • 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 might be interested -- they 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.
  • Reviewers could automatically be made temporary comaintainers of the packages they review so they see that the packager is doing the right things to get it to build in the build system for the first time, etc.
  • co-maintainership maybe could be used in Core, too -- e.g. the primary maintainer with access to the buildsys could be someone from Red Hat, while the co-maintainers are from inside and outside of Red Hat. That probably would help get load of the shoulders from Red Hat maintainers and increase package quality.
  • Packaging-SIGs (like the Extras Games SIG) or their primary members could act as co-maintainers for all packages that fall into the SIGs working area

Plan

  • we need limited access in the VCS and the buildsys -- e.g. new contributors that start as co-maintainers get only access to the packages they co-maintain, but not to the buildsys or to other packages. Note: permission to build has to be added to either the package database or the new account system depending on whether we want building to be a per contributor permission or a person/group-per-package permission.
  • per repo maintainers should be possible -- we probably need a proper the package database for this
  • The package database needs to hold all the information about what role a person plays for a package. The VCS will sync with the package database to control access to the files.
  • primary- and other co-maintainers need to get mails directly into their inbox for everything other maintainers do with a package (commit changes, updates, upload of new files, build requests, pushes). This might need a script to run on commit that queries the package database for people interested in seeing commits to a specific package.
  • The package database would be recording more than just owners for this (Feel free to come up with better names):
  • tier one owners AKA primary owner. Do we want to allow more than one? This person can commit files, request builds, and approve other contributers as co-maintainers, etc.
  • Comaintainers Can commit files and request builds. Should they be able to approve other contributers as maintainers as well?
  • Tier-two maintainers: This is primarily for the "new maintainer" case. The person is not fully sponsored. They can commit files to designated branches of the package but nothing else.
  • Observers: People who want to watch commit emails and bugzilla reports for this package.
  • rules need to be written, e.g.
  • responsibilities between co-maitainer and primary maintainer
  • Bug responsiveness
  • do we need a primary maintainer at all?
  • can N (N=4?) co-maintainers outvote the primary maintainer in case of disputes?
  • can there be takeovers ("I'm doing all the work and my primary maintainer never does anything; I want to take the package over")
  • probably a lot more...
  • "new contributors have to actively co-maintain one package for at least X months before they can take over this or other packages completely (they of course can also take the traditional route with a new package and sponsoring)
  • There are going to be lots of these details. Should we break this up into steps to create this policy?
  • Write down all the "Why we need it" ideas along with any more we come up with.
  • Create a sample structure (Two tiers of maintainers plus observers? Three tiers?) and make sure it will work with all our "Why we need it" cases.
  • Write up rules that describe how one transitions between tiers in the hierarchy and the responsibilities of each level of maintainership.
  • Write up separate documents or add to existing documents to enable the rest of the "Why we need it" cases (Example: Create policy on becoming a contributer by going through co-maintainership instead of package submission. Add this to the "How to get Sponsored" document.)
  • Would it be good to shift our ideas of package ownership? My impression of Core is that the package ownership paradigm is much looser there. Would it be helpful to revamp our view of packages from:
  • Package is owned and maintained by Foo with help from comaintainer Bar and the Baz SIG.

into

  • Package is a part of the Baz SIG and maintained by the members Foo and Bar.

Viewing things this way, packages are always a part of one or more SIGs/groups which have people who have volunteered to take on responsibility for the package in question. Packagers are similarly a part of the SIGs to which the package belongs and can ask the relevant SIGs for help (I am packaging a mono web server which belongs to the mono and internet server SIGs. If the question is whether mono apps are noarch I ask the mono SIG. If the question is whether web servers should each have their own document root, I ask the Internet Server SIG.)

Maybe even a slightly more Wiki-style-approach for maintaining packages in Extras might be a good idea, too.

Short term plans

  • evaluate in detail the technical groundwork we need for proper co-maintainership -- especially package database, VCS, the accounts system and everywhere else; The VCS is currently targeted at FC-7. We need to be sure we have all our requirements put together otherwise that target will slip.

Middle term

  • Wait for the new package database to finish and make sure it offers everything we need (maintainers per dist, ...)
  • encourage co-maintainership in general -- I'd say that 95% of Extras packages should have co-maintainers (the other 5% are packages for special interest areas where only one of the current contributors might bne interested in)
  • especially encourage co-maintainership or even a package hand-over to those people that maintain a lot of or important packages
  • work out detailed rules for co-maintainership (see above)

Long term

  • make sure co-maintainers get mails when one of their packages is changed in CVS or build (people can set up local filters to get something like that but it's often forgotten and likely to break; a feature like this is also interesting for sponsors that want to watch people they sponsored closely). This should be tracked by the package database with a script that watches commits querying the db for the list of people to send to. (Alternately, changes to the package db could set up mail aliases for each package. The script would then only have to send mail to the alais for the package.)
  • make co-maintainership possible in core, too.


Status

  • realize short term plans:
  • evaluate in detail the technical groundwork we need for proper co-maintainership -- especially package database, VCS, the accounts system and everywhere else


Retrieved from "https://fedoraproject.org/w/index.php?title=Extras/Schedule/Comaintainership&oldid=5427"