On Mon, Jul 05, 2010 at 01:30:37PM -0700, Adam Williamson wrote: > > 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. If I recall well, historically, both in fedora extra and fedora core commit rights were pretty liberal. After the merge there was the provenpackagers set up and some packages are more or less protected. But I don't think that what matters is the ACL system, more interesting are the policies and how things are done and why. As you say above the open system fits well 'having quite a small set of maintainers for an extremely large set of packages'. But this is not the case for all of fedora. More precisely, with a bit exageration, there seems to be 4 sets of people. 1) The dedicated community packager works benevolently (though he may be paid for that work and, for example, be a redhat emplyee, it wouldn't matter if he wasn't) and really takes care of his packages. It corresponds, in my opinion to most of former fedora extra packagers and most people at redhat that are hired from the community. For that packager it is important to have people avoid touching his package, but he won't mind if things that are obviously broken are taken care of, especially when he is not available, and he generally have co-maintainers to do the job anyway. (You can guess that I am biased, and find that I am myself in that category). 2) The forced packager has to maintain packages as part of his job. This holds for some people @rh, but not only. For the packages maintained by those packagers, it is better if they are open since they tend not to be very dedicated. Some of them may be picky, however, since they have to make as if they were maintaining their packages, even if they are doing a poor job. Being forced to own a package doesn't mean that, necessarily, the packager will do a poor job, but this is a possibility. 3) The diletante packager is a community packager who steps to do some packaging but after some short time stops without any reason or explanation. I still haven't understood where those come from, what their motivations are, but there are quite a bit in fedora. For the corresponding packages, obviously, having an open system is good. (But having a sponsoring model that avoids them is also good...). 4) The dedicated non community packager is a specie disappearing from fedora, corresponding more or less with packagers, in general redhat old timers who are dedicated but prefer doing things their way. They obviously prefer closed packages. Historically there was a majority of packagers of type 1) in fedora extras and a mix, with, in my opinion, a majority of type 2) and 4) in fedora core. So something closed was more logical, and it was certainly quite different from mandriva. This has moved over the years, with people changing in categories, with some moves in the right direction, mainly from packagers in 2) and 4) going to 1), but, more importantly, there has been people leaving and other entering. Overall, it seems to me that the 2) and 3) are winning over in numbers (category 4) is almost extinct), especially in number of packages. Maybe Fedora should do a transition to a more open system, since the dedicated packager is less present nowadays. But it should be done carefully, in order not to piss off the remaining dedicated packagers, who are those who deliver, in my opinion, the packages with highest quality. -- Pat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel