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
