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

[Kevin F. Quinn (Gentoo)]

On Thu, 27 Apr 2006 10:27:12 -0400
Chris Gianelloni <wolf31o2@g.o> wrote:

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

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

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.

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

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.

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

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.

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.

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

-- 
Kevin F. Quinn


-- 
Kevin F. Quinn