Gentoo Archives: gentoo-dev

From: "Kevin F. Quinn (Gentoo)" <kevquinn@g.o>
To: gentoo-dev@l.g.o
Cc: seemant@g.o
Subject: Re: [gentoo-dev] Herds, Teams and Projects
Date: Thu, 27 Apr 2006 17:55:05
In Reply to: Re: [gentoo-dev] Herds, Teams and Projects by Chris Gianelloni
1 On Thu, 27 Apr 2006 10:27:12 -0400
2 Chris Gianelloni <wolf31o2@g.o> wrote:
4 > On Thu, 2006-04-27 at 09:22 +0200, Kevin F. Quinn (Gentoo) wrote:
5 > > I must admit I've assumed that the herd entry in metadata.xml is a
6 > > reasonable fall-back if the maintainer entry is missing or the
7 > > listed maintainer is away/not responding. This is implied by
8 > > which
9 > > requires <herd> but not <maintainer> - also the description of
10 > > <maintainer> says "Besides being a member of a herd, a package can
11 > > also be maintained directly" which implies the herd is the default
12 > > maintainer if maintainer is not present.
13 >
14 > Well, the herd listing shows what herd that it belongs to, not the
15 > team that manages that herd. I think that this is the confusion. For
16 > example, catalyst has livecd listed as its herd. However, there is
17 > not a "livecd" project, nor team. Instead, the "livecd" herd is
18 > maintained by myself, solely, except for genkernel and catalyst, that
19 > have alternate maintainers. In the case of catalyst, an alias is
20 > listed as the maintainer, since there *is* a catalyst team, albeit
21 > small.
22 >
23 > > The herds project description says, "The herds project aims to
24 > > ensure that the growing number of ebuilds do not overwelm (sic) the
25 > > gentoo project. To this end the herds project aims for the
26 > > development of infrastructure that will help manage the collection
27 > > of ebuilds". This clearly indicates herds are supposed to have a
28 > > maintainer role.
29 >
30 > Where?
32 Two places. First, in the description of maintainer:
34 "Besides being a member of a herd, a package can also be maintained
35 directly"
37 which implies packages can be maintained by being a member of a herd and
38 secondly where it says:
40 "[herds] help manage the collection of ebuilds"
42 I interpreted "manage" to include "maintain", since I couldn't think
43 of any other management that needs to be done.
45 If we're to distinguish between herds and teams, and it seems that we
46 should, clearly something needs to define which teams maintain which
47 herds.
49 > I can see how you can interpret it like that, but it is anything but
50 > clear in stating it. In fact, it mentions nothing about maintaining
51 > any packages, but rather to "manage the collection" of them, which
52 > leads me to read it as it is there solely for creating a logical
53 > grouping of specific packages, much like how categories work in the
54 > tree itself. For example, look at openal. It is a package in the
55 > "sound" herd, yet the sound *team* does not maintain it. I do.
56 >
57 > > A quick scan of the tree shows that some 6k+ packages have no
58 > > maintainer entry.
59 >
60 > Well, ~700 of those are games, which belong to the games herd, and
61 > have no specific maintainer. The games *team* maintains all packages
62 > in the games herd that does not have a specific maintainer listed.
63 > It just so happens that in *many* cases, the project (or team) has
64 > the same name as the herd to which the package belongs. I think that
65 > this has been the cause of the confusion, more than the definitions.
67 I do think that metadata.xml should always indicate who maintains a
68 package, whether it's a single maintainer or a team of maintainers -
69 including who is the backup should the primary maintainer be
70 unavailable for an urgent change. If the herd is nothing to do with who
71 maintains a package, then the maintainer entry should be mandatory;
72 there can be multiple entries and it's easy enough to set up team mail
73 aliases. I also think it should be clear in metadata.xml who the
74 "backup" maintainers are if such exist - i.e. someone who can process
75 stuff in the absence of the primary maintainer.
77 Maybe other people were assuming, like me, that if maintainer is
78 missing then the herd was the mail alias to write to. I can see from
79 what you're saying that the herd name is not a mail alias (since it
80 doesn't refer to people).
82 It definitely seems that we need to define somewhere which teams
83 maintain which herds. The games example is perhaps obvious, but in
84 general that won't be the case.
86 Perhaps for simplicity (and to save having to edit 6k+ metadata.xml
87 files), we could rule that if the maintainer entry is missing, and the
88 herd name is the same as a team name, that team is the maintainer for
89 the package.
91 > > It would be useful to know how many people think herds are not
92 > > maintainers - if only a few people think this then I suggest it
93 > > would be better to accept the common interpretation of herd as a
94 > > group of people who can maintain a package.
95 >
96 > I definitely do not think that herds are maintainers. At the same
97 > time, I understand that many people do think this, so I'm willing to
98 > change *my* definition to match what the in practice definition ends
99 > up being, if necessary.
101 So what are the herds supposed to achieve? It would be useful to see
102 some examples of what herds are/could be useful for. I'm happy to go
103 with the intended definition of herd, but it certainly could be clearer
104 in the documentation.
106 --
107 Kevin F. Quinn
110 --
111 Kevin F. Quinn


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


Subject Author
Re: [gentoo-dev] Herds, Teams and Projects Chris Gianelloni <wolf31o2@g.o>