On Wed, 2016-02-03 at 08:44 -0700, Jerry James wrote: > > I think we need to ask ourselves, as a project, what behaviors we want > to motivate and what behaviors we want to demotivate in our packagers. > I think we need to take human nature, flawed as it is, into account > when doing so. I fear that this "nobody owns any packages" mantra is > not providing the motivations and demotivations that we really want. I agree. I believe that package ownership has at least a couple of clear advantages for obvious reasons and I find it hard to understand how people can discount their usefulness. 1) A point of contact and co-ordination for changes is needed. Often, when dealing with difficult problems it's necessary to seek advice from maintainers of other packages. Being able to find out who that is and having at least some chance they will be familiar with upstream package status is important. 2) Taking (even notional) ownership of a package implies there is at least some interest in the package from an upstream POV. Some (probably many) packages need a packager to take an interest in what is happening upstream. Building relationships with upstream maintainers doesn't always work too well but even that is an important part of knowing what the upstream status of a package is. This is essential to be able to provide 1) above, someone who has some understanding of the upstream status really is needed to at least help keep our packages as stable as we can. It's true that package owners don't always have enough upstream knowledge of packages they own or relationships with upstream but that doesn't mean that ownership is a bad thing. After all a point of contact is still needed IMHO. I fail to see how allowing ad-hoc changes to packages, which will often not even involve letting others interested in the package know what has happened, will lead to improvement overall. If the goal is to reduce the barrier for others to contribute then that doesn't necessarily mean doing away with package owners. It means defining processes to allow this while keeping the owner (the one that probably has some idea of the upstream package status) in the loop. Whether that also means power of veto over changes is slightly different but somehow I think that must be the case to maximize package stability. It might be obvious that my view is influenced a lot because I'm also an upstream package maintainer. Clearly I strongly believe in the need for downstream packagers to be in touch with what's happening upstream. And, yes, it can be hard to take the "no" or "I don't like that change" or an "I'm not going to do that" but that is all part of working with upstream and knowing a package, the bit downstream packagers seem to miss all too often IMHO. Don't forget, the relationship (that is needed) is just as hard for upstream as it is for downstream, that's just life. Ian -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx