1 |
Moving the discussion to -dev per leios request. |
2 |
|
3 |
On Wed, 21 May 2008 23:42:19 +0200 |
4 |
Marius Mauch <genone@g.o> wrote: |
5 |
|
6 |
> As this topic jus came up in #-dev, and most people there seemed to |
7 |
> agree with me I thought it might be worth to bring this topic up |
8 |
> again. The topic is that I think that the whole 'herd' concept we're |
9 |
> using is a huge mess and should be removed. Now before eveyone starts |
10 |
> screaming, lets look at what this concept actually is, as many people |
11 |
> are quite confused by it: |
12 |
> |
13 |
> 1) a herd is a group of packages (not a group of people) |
14 |
> 2) the herds.xml file is used to assign people and mail aliases as |
15 |
> maintainers of a given herd. Unfortuntely the syntax there give |
16 |
> the impression that those people/mail aliases actually form the herd |
17 |
> 3) the <herd> tag in metadata.xml is used to assign a package to a |
18 |
> certain group. |
19 |
> 4) the <maintainer> tag in metadata.xml can be used to assign |
20 |
> individual maintainers for a package in addition to/instead of the |
21 |
> herd maintainers |
22 |
> 5) the combination of 2), 3) and 4) is used to determine the |
23 |
> maintainers of a given package |
24 |
> |
25 |
> Now most people will be familiar with 5) to some degree, and that is |
26 |
> actually the only valid use case for the herd concept that I'm aware |
27 |
> of. Or has anyone some use case where you'd like to know what herd a |
28 |
> package belongs to, but don't care about by whom that herd is |
29 |
> maintained? |
30 |
> If we can agree that this is the only real use case for the herd |
31 |
> concept, then I think the concept is quite useless as it's just a |
32 |
> redundant layer of indirection. You could just list mail aliases |
33 |
> directly as maintainers, without having to consult herds.xml first. |
34 |
> |
35 |
> This would have a number of benefits: |
36 |
> - you no longer have to look at herds.xml to determine the actual |
37 |
> maintainers of a given package (as herd-name and associated mail alias |
38 |
> don't always match) |
39 |
> - it would simplify bug assignment rules, as the current case where a |
40 |
> package has both a <herd> and a <maintainer> tag in metadata.xml no |
41 |
> longer exists |
42 |
> - eliminate confusion about what a herd actually is |
43 |
> - only have one location where members of a given team are listed, |
44 |
> currently it's possible and quite likely that herds.xml and the mail |
45 |
> alias files get out of sync |
46 |
> - as others said in #-dev: it makes sense ;) |
47 |
> |
48 |
> Now there of course are a few things to consider: |
49 |
> - obviously, some tools, docs and processes would have to be updated, |
50 |
> but that's always the case with changes |
51 |
> - someone said that it might no longer be obvious if a package is |
52 |
> maintained by an individual or a group of people. But is that really |
53 |
> necessary? And it's not even obvious now, as some herds are maintained |
54 |
> by a single person. |
55 |
> - when I brought this up several months ago it was mentioned that |
56 |
> sometimes people want to be on the mail alias of a herd, but don't |
57 |
> want to be listed as members (and therefore be responsible). But that |
58 |
> can likely be just implemented by some kind of blacklist in the |
59 |
> relevant tools instead of using this whole indirection layer all the |
60 |
> time. |
61 |
> |
62 |
> So, what do you think? Is there some benefit in keeping this concept, |
63 |
> or can we live without it and make life simpler for everyone? |
64 |
> |
65 |
> Marius |
66 |
> |
67 |
> -- |
68 |
> Public Key at http://www.genone.de/info/gpg-key.pub |
69 |
> |
70 |
> In the beginning, there was nothing. And God said, 'Let there be |
71 |
> Light.' And there was still nothing, but you could see a bit better. |
72 |
|
73 |
|
74 |
-- |
75 |
Public Key at http://www.genone.de/info/gpg-key.pub |
76 |
|
77 |
In the beginning, there was nothing. And God said, 'Let there be |
78 |
Light.' And there was still nothing, but you could see a bit better. |