On Sat, 2006-07-29 at 15:52 +0200, Thorsten Leemhuis wrote:
> Hi all!
>
> Welcome everybody to my brain dump of ideas around co-maintainership for
> Fedora Extras.
>
> == Why we need it ==
[snip]
I agree with every one of those uses for co-maintainership. We might
have to break out the rules for them into several different documents
but they all seem to be things we really want to enable.
> == What we need to make all that happen ==
>
> * we need limited access in the VCS -- 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
>
I think this will need to be implemented partially in the VCS and
partially in the buildsys. The VCS will keep packagers from committing
changes to packages they aren't comaintainers of. The buildsys will
have to be smart enough not to queue packages from maintainers that
don't have the build permissions.
* 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
>
Yes. For the previous point as well. 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 needs 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?
1) Write down all the "Why we need it" ideas along with any more we come
up with.
2) 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.
3) Write up rules that describe how one transitions between tiers in the
hierarchy and the responsibilities of each level of maintainership.
2 + 3 = the base policy for co-maintainership.
4) 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.)
>
> == Action plan ==
>
> === Short term ===
>
> * Fix bugzilla auto-CC in owners.list -- see
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198109
>
Hmm.. The last entry there is asking for input from Sopwith but he's on
extended leave. Maybe someone should ping warren or mmcgrath about
this.
> * 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, ...)
>
is there someone assigned to this? I thought someone in Infrastructure
was looking into this but I'm looking at the Infrastructure Schedule and
it's not on there....
> * 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
>
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.)
Potential difficulties are that there may not presently be a SIG for
every package. We can create them (Educational SIG, Science SIG, File
Server SIG, Version Control SIG....) but it may not work as well if the
SIGs don't grow organically.... Organization of the SIGs might also be
a problem but we could use something like Trove categories....
> * 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.
>
The Great Merge is the goal for our generation of Fedora. What will be
the goal for the Post-Merge generation? :-)
-Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
