concept of package "ownership"

Adam Williamson awilliam at redhat.com
Mon Jul 5 20:30:37 UTC 2010


On Fri, 2010-07-02 at 03:18 +0200, Kevin Kofler wrote:

> I think we need to get rid of the concept of ownership entirely, that'd also 
> make orphaned or de-facto orphaned packages less of a problem. You see a 
> problem, you fix it. Who cares whether the package has an active maintainer 
> or not?

I think there's a reasonable middle ground here. Mandriva has a very
open ACL policy. Anyone with commit access to a repository has commit
access to every package in that repository, so any MDV maintainer can
change any package in contrib, and anyone who maintains a package in
main - which, practically speaking, is a lot of people including many
non-staff - can change any package in main. There's a very small list of
restricted packages to which this doesn't apply; I think that's pretty
much just kernel and glibc or something very minimal like that.

In practice, packages still have maintainers who are recognized for
practical reasons and generally you would check with the listed
maintainer of a package before making a change to it. (But, hey, if they
don't reply in a day or two, it's fair game!)

This generally works out pretty well, and helps out with the problem of
having quite a small set of maintainers for an extremely large set of
packages. I was often in the situation where I happened to notice a
small issue with 'someone else's' package and could just go ahead and
fix it, instead of having to go through the bureaucracy of filing a bug
report and waiting for them to do it. It's rarely the case that someone
makes a really stupid change and causes friction. I'd say the system
works more often than it doesn't, and it'd probably be good for Fedora
too to - as Dave proposes - explicitly _not_ have a concept of
ownership, and be more liberal about non-maintainers touching packages.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



More information about the devel mailing list