Gentoo Archives: gentoo-project

From: Marius Mauch <genone@g.o>
To: gentoo-dev@g.o
Cc: gentoo-project@l.g.o
Subject: Re: [gentoo-project] About herds and their non-existant use
Date: Wed, 21 May 2008 23:40:15
Message-Id: 20080522013603.0e4bf658@sheridan.genone.homeip.net
In Reply to: [gentoo-project] About herds and their non-existant use by Marius Mauch
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.

Attachments

File name MIME type
signature.asc application/pgp-signature