On Thu, Dec 11, 2014 at 1:23 AM, Michael Palimaka <kensing...@gentoo.org> wrote: > > This would be by far the easiest solution. Some herds already have an > alias like this eg. freedesktop -> freedesktop-bugs. Much easier than > mass-editing every single metadata.xml with what amounts to a cosmetic > change. >
I think we're not all on the same page about what we're trying to accomplish. I think we need to agree on that before we can really agree on how to do it. There are many goals here that I can see: 1. Simplification of the xml schema so that we don't have so many different kinds of tags with different rules for each. 2. Simplification of how we track group (ie project/herd/alias/etc) member lists so that they're not in 5 different places with 5 different ways of determining who is in a group. 3. Avoiding having large groups of packages maintained by large groups of devs where the reality is that many packages aren't maintained by anybody but this is opaque. 4. If not all of the emails associated with metadata are considered true maintainers, making it easy to tell which ones are and aren't. I don't think all of these have equal support, which is why we end up debating different solutions (obviously a solution which addresses all of these is going to be more intrusive than a solution that only addresses some of these). I've been a proponent of solving all of these, but perhaps it would make more sense to start smaller than that. The only catch is that if we remove the distinction in metadata between maintainers/proxies/projects/herds/etc then if that distinction becomes more important in the future it becomes harder to tell which ones are which. Part of me is wondering if worrying about #3-4 is actually all that productive. Does it really matter if a package is maintained or not, when it all comes down to it? Does it make more sense to focus on whether packages have serious problems? Maybe if a package is completely unmaintained it makes it easier for developers to drop in and make changes without asking anybody about it first, versus logging a bug, waiting for the maintainer to drop the ball, and then making the change anyway. -- Rich
