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

[Chris Gianelloni]

On Thu, 2006-04-27 at 09:22 +0200, Kevin F. Quinn (Gentoo) wrote:
> I must admit I've assumed that the herd entry in metadata.xml is a
> reasonable fall-back if the maintainer entry is missing or the listed
> maintainer is away/not responding.  This is implied by
> http://www.gentoo.org/proj/en/metastructure/herds/index.xml which
> requires <herd> but not <maintainer> - also the description of
> <maintainer> says "Besides being a member of a herd, a package can also
> be maintained directly" which implies the herd is the default maintainer
> if maintainer is not present.

Well, the herd listing shows what herd that it belongs to, not the team
that manages that herd.  I think that this is the confusion.  For
example, catalyst has livecd listed as its herd.  However, there is not
a "livecd" project, nor team.  Instead, the "livecd" herd is maintained
by myself, solely, except for genkernel and catalyst, that have
alternate maintainers.  In the case of catalyst, an alias is listed as
the maintainer, since there *is* a catalyst team, albeit small.

> The herds project description says, "The herds project aims to ensure
> that the growing number of ebuilds do not overwelm (sic) the gentoo
> project. To this end the herds project aims for the development of
> infrastructure that will help manage the collection of ebuilds".  This
> clearly indicates herds are supposed to have a maintainer role.

Where?

I can see how you can interpret it like that, but it is anything but
clear in stating it.  In fact, it mentions nothing about maintaining any
packages, but rather to "manage the collection" of them, which leads me
to read it as it is there solely for creating a logical grouping of
specific packages, much like how categories work in the tree itself.
For example, look at openal.  It is a package in the "sound" herd, yet
the sound *team* does not maintain it.  I do.

> A quick scan of the tree shows that some 6k+ packages have no
> maintainer entry.

Well, ~700 of those are games, which belong to the games herd, and have
no specific maintainer.  The games *team* maintains all packages in the
games herd that does not have a specific maintainer listed.  It just so
happens that in *many* cases, the project (or team) has the same name as
the herd to which the package belongs.  I think that this has been the
cause of the confusion, more than the definitions.

> 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.

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