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