First: thx for bringing this up again after a similar idea/concept got lost in the merge. On 05.10.2007 23:57, Toshio Kuratomi wrote: > > = Unsponsored Comaintainers = I really dislike this term -- even a single contributor that want to get hands only on one package needs someone to oversee him. In the document below it's called mentor, but in fact the job is similar to the sponsers job. I'd prefer to get contributor levels in a easy form. E.g. contributor level 1 -> what you outlined here contributor level 2 -> what most contributors are right now contributor level 3 -> sponsors right now contributor from level <n> should oversee (aka sponsor) contributor from level < n -1 > Should we even need more levels we can redefine the current ones and put one in between. E.g. "contributor level 2b -- people that contribute for some time now where the sponser stopped looking after each step of that contributer" > Sometimes a contributor wants to get involved with a single Fedora > package. This is often the case with upstream maintainers who are > interested in seeing their software run well on Fedora but either lack > the time to participate in or are disinterested in Fedora as a whole. I think we should have a broader approach -- the concept should IMHO be used for getting new contributors in even if they are not upstream maintainers. E.g. like: foo> I want to contribute to Fedora bar> are there any packages you are interested in? foo> foobar and barfoo * bar looks if those have co-maintainers already bar> please ask baz; he maintains foobar alone until now; you could become co-maintainer without build rights and baz will oversee your work; if you're doing well for some months you'll get full access and baz has more time to work on <more complicated stuff> > One way to enable this is to have current Fedora Packagers "mentor" the > upstream maintainers. Was "upstream maintainers" only meant as example or do you want to limit it to them? > The Fedora Packager can be the owner of record > for the package and make sure that it integrates with the rest of > Fedora. The upstream maintainer would take the role of comaintainer for > the package and help mainly with code-related bugs. > > For this sort of work, it would be ideal if the comaintainer could > commit to the package but not build or push. The package owner would > then have the ability to check the changes that the upstream maintainer > made to verify they followed the Fedora Packaging Guidelines and > integrated with things going on in the rest of the distro. > > At the moment we are constrained by the limitations of the tools we're > working with (koji, packagedb, cvs repository, and bodhi). So here's a > three phase approach to getting to the ideal: > > == Phase 1 == > > Upstream maintainer and Fedora Package owner decide to collaborate. The > Upstream maintainer signs the CLA. Someone from a group of sponsors > willing to work on this as a pilot program sponsors them into cvsextras. > > The comaintainer can now request commit acls on the package. This gives > them access to commit to cvs, build in koji, and push via bodhi for this > package. There is an understanding among the participants that the > upstream maintainer should not work on packages for which they have not > been granted commit access. Even more people that easily get access to all our packages? Sounds ridiculous to me (sorry for using such hard words) as you'll likely remember from previous discussions. > The sponsor has to watch the commits list > for changes made by the upstream maintainer that violate this policy. More load on those rare people. I don't think that's wise and I doubt many sponsors will sponsor "Unsponsored Comaintainers" > This requires no changes to our tools but requires: > 1) a pool of sponsors willing to work on this > 2) commitment from unsponsored comaintainers to follow the rules and > sponsors who are willing to police those comaintainers to make sure > they're abiding by them. > > == Phase 2 == > > In phase 2, we can remove the pool of sponsors. Instead we allow people > without cvsextras to sign up to comaintain a package. If the primary > package maintainer approves, the comaintainer is allowed to use any of > the acls they are approved for. The package owner would still have to > watch to make sure the comaintainer is not doing more than they are > supposed to on that particular package. That sounds way better then phase 1. > This requires changes to the cvs repository so people not in cvsextras > but explicitly in the acl are allowed to commit. This could be a bit > tricky as we currently have two levels of security in the repository: 1) > People must be in the acl to access resources of the repository, 2) they > must be in cvsextras. We'll want something equivalent in the new setup. /me wonders what the status of the "new VCS" is and how it matters to this plan > == Phase 3 == > > In this stage, we make sure that acls prevent people from doing things > they are not supposed to, freeing the package owner from some of the > manual policing they had to do before. The PackageDB will have acls for > pushing and building as well as committing. This will allow package > owners to specify that a maintainer should only be allowed to commit or > only allowed to commit and build. [...] Sounds good to me. Cu knurd -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
