Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Herds, Teams and Projects
Date: Thu, 27 Apr 2006 19:09:08
In Reply to: Re: [gentoo-dev] Herds, Teams and Projects by "Kevin F. Quinn (Gentoo)"
1 On Thu, 2006-04-27 at 19:54 +0200, Kevin F. Quinn (Gentoo) wrote:
2 > > Where?
3 >
4 > Two places. First, in the description of maintainer:
5 >
6 > "Besides being a member of a herd, a package can also be maintained
7 > directly"
8 >
9 > which implies packages can be maintained by being a member of a herd and
11 No, it doesn't. It *plainly* states that a package is a member of a
12 herd, *or* it can also be maintained by a person. The problem is that
13 there's nothing stating that a herd is maintained by a team or a
14 project.
16 > secondly where it says:
17 >
18 > "[herds] help manage the collection of ebuilds"
19 >
20 > I interpreted "manage" to include "maintain", since I couldn't think
21 > of any other management that needs to be done.
23 We read this differently. I read this as:
25 manage the collection ... of ebuilds
27 You read it as:
29 manage the ... collection of ebuilds
31 I can see where that can be confusing. Perhaps some better wording
32 there would clear it up.
34 > If we're to distinguish between herds and teams, and it seems that we
35 > should, clearly something needs to define which teams maintain which
36 > herds.
38 Most are on the project pages, already. The biggest failure here is
39 that there aren't project pages for all of the projects (or teams) out
40 there maintaining packages.
42 As an example, look at the output from the following piece of GuideXML
43 from the page.
45 <herd name="games"/>
47 This gives the following output on the page:
49 4. Herds
51 The Games project maintains the following herds:
53 Herd
54 Members
55 Description
56 games
57 Mr_Bones_, Tupone,
58 genstef, vapier,
59 wolf31o2
60 Gentoo Games Team
62 This clearly shows the relationship of a project to a herd, yet *also*
63 helps in confusing the issue by listing the developers responsible for
64 the herd, as *members* of the herd.
66 > I do think that metadata.xml should always indicate who maintains a
67 > package, whether it's a single maintainer or a team of maintainers -
68 > including who is the backup should the primary maintainer be
69 > unavailable for an urgent change. If the herd is nothing to do with who
70 > maintains a package, then the maintainer entry should be mandatory;
71 > there can be multiple entries and it's easy enough to set up team mail
72 > aliases. I also think it should be clear in metadata.xml who the
73 > "backup" maintainers are if such exist - i.e. someone who can process
74 > stuff in the absence of the primary maintainer.
76 I'd tend to agree with you here. The main thing is that in most cases,
77 the project/team maintaining the packages has the exact same name as the
78 herd it maintains, which would make the extra data a bit redundant.
79 After all, do we really need:
81 <herd>games</herd>
82 <maintainer>games@g.o</maintainer>
84 The data is fairly redundant, in this case. Perhaps what we need more
85 is a single location that maps the list of projects/teams to packages?
87 > Maybe other people were assuming, like me, that if maintainer is
88 > missing then the herd was the mail alias to write to. I can see from
89 > what you're saying that the herd name is not a mail alias (since it
90 > doesn't refer to people).
92 I would venture a bet that in most, if not all cases in the tree, that
93 you are absolutely correct. The herd name generally corresponds with
94 the team name. I can think of a few exceptions to this rule, such as
95 portage bugs go to dev-portage, rather than portage. There are also
96 examples of project/team email aliases being listed as the maintainer,
97 such as with catalyst or sandbox.
99 > It definitely seems that we need to define somewhere which teams
100 > maintain which herds. The games example is perhaps obvious, but in
101 > general that won't be the case.
103 It's listed on the games project page, as is the case in quite a few
104 other projects, and should be the case in *all* projects/teams.
106 > Perhaps for simplicity (and to save having to edit 6k+ metadata.xml
107 > files), we could rule that if the maintainer entry is missing, and the
108 > herd name is the same as a team name, that team is the maintainer for
109 > the package.
111 That would be fine and tends to match what we are currently using,
112 meaning there's no change in behavior required. The only files that
113 would/should need editing are ones where the herd name does not directly
114 correspond with the project/team alias, such as my given portage
115 example.
117 > > > It would be useful to know how many people think herds are not
118 > > > maintainers - if only a few people think this then I suggest it
119 > > > would be better to accept the common interpretation of herd as a
120 > > > group of people who can maintain a package.
121 > >
122 > > I definitely do not think that herds are maintainers. At the same
123 > > time, I understand that many people do think this, so I'm willing to
124 > > change *my* definition to match what the in practice definition ends
125 > > up being, if necessary.
126 >
127 > So what are the herds supposed to achieve? It would be useful to see
128 > some examples of what herds are/could be useful for. I'm happy to go
129 > with the intended definition of herd, but it certainly could be clearer
130 > in the documentation.
132 Well, the idea was to group like packages together. For example, we
133 could have a "qmail" herd, that would encompass packages in any and all
134 categories in the tree. That herd could be maintained by a team (or
135 teams). Truthfully, we have some very large herds of fairly diverse
136 packages. For example, we have the "net-mail" herd that is responsible
137 for both postfix and sendmail, which are *very* different packages.
138 They end up not being maintained by the same people, at all. Of course,
139 both of these packages have individual maintainers listed, but it gets
140 the point across. A better solution here would probably be to split up
141 net-mail into smaller herds, and have a single "mail" project/team that
142 is responsible, as a whole, for the multiple mail-related herds.
143 Members within a team can have specific responsibilities within that
144 team, so this isn't an issue.
146 There are few examples of a single team maintaining multiple herds, but
147 it could be done. As an example, we could take all of the games that
148 require people to actually buy something, and create a
149 "games-commercial" herd, which would be maintained by a team of
150 developers that actually owned the games. In practice, this is exactly
151 what happens. It just happens internal to the games team and isn't
152 formalized, though it is listed on our project page. ;]
154 --
155 Chris Gianelloni
156 Release Engineering - Strategic Lead
157 x86 Architecture Team
158 Games - Developer
159 Gentoo Linux


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