1 |
Marius Mauch wrote: |
2 |
|
3 |
> Moving the discussion to -dev per leios request. |
4 |
> |
5 |
> On Wed, 21 May 2008 23:42:19 +0200 |
6 |
> Marius Mauch <genone@g.o> wrote: |
7 |
> |
8 |
>> As this topic jus came up in #-dev, and most people there seemed to |
9 |
>> agree with me I thought it might be worth to bring this topic up |
10 |
>> again. The topic is that I think that the whole 'herd' concept we're |
11 |
>> using is a huge mess and should be removed. Now before eveyone starts |
12 |
>> screaming, lets look at what this concept actually is, as many people |
13 |
>> are quite confused by it: |
14 |
>> |
15 |
>> 1) a herd is a group of packages (not a group of people) |
16 |
>> 2) the herds.xml file is used to assign people and mail aliases as |
17 |
>> maintainers of a given herd. Unfortuntely the syntax there give |
18 |
>> the impression that those people/mail aliases actually form the herd |
19 |
>> 3) the <herd> tag in metadata.xml is used to assign a package to a |
20 |
>> certain group. |
21 |
>> 4) the <maintainer> tag in metadata.xml can be used to assign |
22 |
>> individual maintainers for a package in addition to/instead of the |
23 |
>> herd maintainers |
24 |
>> 5) the combination of 2), 3) and 4) is used to determine the |
25 |
>> maintainers of a given package |
26 |
>> |
27 |
>> Now most people will be familiar with 5) to some degree, and that is |
28 |
>> actually the only valid use case for the herd concept that I'm aware |
29 |
>> of. Or has anyone some use case where you'd like to know what herd a |
30 |
>> package belongs to, but don't care about by whom that herd is |
31 |
>> maintained? |
32 |
>> If we can agree that this is the only real use case for the herd |
33 |
>> concept, then I think the concept is quite useless as it's just a |
34 |
>> redundant layer of indirection. You could just list mail aliases |
35 |
>> directly as maintainers, without having to consult herds.xml first. |
36 |
While I think the herds concecpt is somewhat useless, I'd rather like to see |
37 |
something like this instead: |
38 |
|
39 |
<maintainer> |
40 |
<team>foobar</team> |
41 |
</maintainer> |
42 |
|
43 |
This makes it clear that it is a team instead of a person (where <name> |
44 |
would have been used) |
45 |
|
46 |
And the herds.xml isn't completely useless, but I'd rather name it teams.xml |
47 |
and list the teams there. This way we can validated the team mentioned in |
48 |
<team>...</team> against the list of available teams and make sure the |
49 |
complete thing is valid (can be done in the current metadata.dtd or in a |
50 |
future metadata.xsd). |
51 |
(If we're gonna re-use the <email>...</email> element for the herd-alias, we |
52 |
can never validate it. And I'm personally for the: "if something can be |
53 |
automatically validated, it should be") |
54 |
|
55 |
>> |
56 |
>> This would have a number of benefits: |
57 |
>> - you no longer have to look at herds.xml to determine the actual |
58 |
>> maintainers of a given package (as herd-name and associated mail alias |
59 |
>> don't always match) |
60 |
I don't consider this much of a problem. You just have to know xsl/xpath to |
61 |
cope with this as generating the list of mail-aliases to assign this bug to |
62 |
is a simple xsl-transformation... |
63 |
When we use XML we can also use the right tools to handle them, can't we? |
64 |
|
65 |
>> - it would simplify bug assignment rules, as the current case where a |
66 |
>> package has both a <herd> and a <maintainer> tag in metadata.xml no |
67 |
>> longer exists |
68 |
It doesn't. You can still have more than one <maintainer> in there. |
69 |
We'd have to introduce an attribute to mark the primary maintainer. |
70 |
|
71 |
>> - eliminate confusion about what a herd actually is |
72 |
++ |
73 |
|
74 |
>> - only have one location where members of a given team are listed, |
75 |
>> currently it's possible and quite likely that herds.xml and the mail |
76 |
>> alias files get out of sync |
77 |
Well, we need one location where the name of the team is mapped to the |
78 |
actual mail-alias. But I don't get what you're trying to say... |
79 |
|
80 |
|
81 |
Cheers, |
82 |
Tiziano |
83 |
|
84 |
|
85 |
-- |
86 |
gentoo-dev@l.g.o mailing list |