Re: [gentoo-dev] Herds, Teams and Projects

[Chris Gianelloni]

On Thu, 2006-04-27 at 19:54 +0200, Kevin F. Quinn (Gentoo) wrote:
> > Where?
>
> Two places. First, in the description of maintainer:
>
> "Besides being a member of a herd, a package can also be maintained
> directly"
>
> which implies packages can be maintained by being a member of a herd and

No, it doesn't.  It *plainly* states that a package is a member of a
herd, *or* it can also be maintained by a person.  The problem is that
there's nothing stating that a herd is maintained by a team or a
project.

> secondly where it says:
>
> "[herds] help manage the collection of ebuilds"
>
> I interpreted "manage" to include "maintain", since I couldn't think
> of any other management that needs to be done.

We read this differently.  I read this as:

manage the collection ... of ebuilds

You read it as:

manage the ... collection of ebuilds

I can see where that can be confusing.  Perhaps some better wording
there would clear it up.

> If we're to distinguish between herds and teams, and it seems that we
> should, clearly something needs to define which teams maintain which
> herds.

Most are on the project pages, already.  The biggest failure here is
that there aren't project pages for all of the projects (or teams) out
there maintaining packages.

As an example, look at the output from the following piece of GuideXML
from the http://www.gentoo.org/proj/en/desktop/games/index.xml page.

<herd name="games"/>

This gives the following output on the page:

4. Herds

The Games project maintains the following herds: 

Herd
Members
Description
games
Mr_Bones_, Tupone,
genstef, vapier,
wolf31o2
Gentoo Games Team

This clearly shows the relationship of a project to a herd, yet *also*
helps in confusing the issue by listing the developers responsible for
the herd, as *members* of the herd.

> I do think that metadata.xml should always indicate who maintains a
> package, whether it's a single maintainer or a team of maintainers -
> including who is the backup should the primary maintainer be
> unavailable for an urgent change. If the herd is nothing to do with who
> maintains a package, then the maintainer entry should be mandatory;
> there can be multiple entries and it's easy enough to set up team mail
> aliases.  I also think it should be clear in metadata.xml who the
> "backup" maintainers are if such exist - i.e. someone who can process
> stuff in the absence of the primary maintainer.

I'd tend to agree with you here.  The main thing is that in most cases,
the project/team maintaining the packages has the exact same name as the
herd it maintains, which would make the extra data a bit redundant.
After all, do we really need:

<herd>games</herd>
<maintainer>games@g.o</maintainer>

The data is fairly redundant, in this case.  Perhaps what we need more
is a single location that maps the list of projects/teams to packages?

> Maybe other people were assuming, like me, that if maintainer is
> missing then the herd was the mail alias to write to.  I can see from
> what you're saying that the herd name is not a mail alias (since it
> doesn't refer to people).

I would venture a bet that in most, if not all cases in the tree, that
you are absolutely correct.  The herd name generally corresponds with
the team name.  I can think of a few exceptions to this rule, such as
portage bugs go to dev-portage, rather than portage.  There are also
examples of project/team email aliases being listed as the maintainer,
such as with catalyst or sandbox.

> It definitely seems that we need to define somewhere which teams
> maintain which herds.  The games example is perhaps obvious, but in
> general that won't be the case.

It's listed on the games project page, as is the case in quite a few
other projects, and should be the case in *all* projects/teams.

> Perhaps for simplicity (and to save having to edit 6k+ metadata.xml
> files), we could rule that if the maintainer entry is missing, and the
> herd name is the same as a team name, that team is the maintainer for
> the package.

That would be fine and tends to match what we are currently using,
meaning there's no change in behavior required.  The only files that
would/should need editing are ones where the herd name does not directly
correspond with the project/team alias, such as my given portage
example.

> > > It would be useful to know how many people think herds are not
> > > maintainers - if only a few people think this then I suggest it
> > > would be better to accept the common interpretation of herd as a
> > > group of people who can maintain a package.
> >
> > I definitely do not think that herds are maintainers.  At the same
> > time, I understand that many people do think this, so I'm willing to
> > change *my* definition to match what the in practice definition ends
> > up being, if necessary.
>
> So what are the herds supposed to achieve?  It would be useful to see
> some examples of what herds are/could be useful for.  I'm happy to go
> with the intended definition of herd, but it certainly could be clearer
> in the documentation.

Well, the idea was to group like packages together.  For example, we
could have a "qmail" herd, that would encompass packages in any and all
categories in the tree.  That herd could be maintained by a team (or
teams).  Truthfully, we have some very large herds of fairly diverse
packages.  For example, we have the "net-mail" herd that is responsible
for both postfix and sendmail, which are *very* different packages.
They end up not being maintained by the same people, at all.  Of course,
both of these packages have individual maintainers listed, but it gets
the point across.  A better solution here would probably be to split up
net-mail into smaller herds, and have a single "mail" project/team that
is responsible, as a whole, for the multiple mail-related herds.
Members within a team can have specific responsibilities within that
team, so this isn't an issue.

There are few examples of a single team maintaining multiple herds, but
it could be done.  As an example, we could take all of the games that
require people to actually buy something, and create a
"games-commercial" herd, which would be maintained by a team of
developers that actually owned the games.  In practice, this is exactly
what happens.  It just happens internal to the games team and isn't
formalized, though it is listed on our project page.  ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux