On Tue, 9 Sep 2014 21:45:49 +0200
Michał Górny <mgo...@gentoo.org> wrote:

> Hello,
> 
> Let's keep it short: I think herds don't serve any special purpose
> nowadays. Their existence is mostly resulting in lack of consistency
> and inconveniences.
> 
> In particular:
> 
> 1. We have two different tags in metadata.xml that serve a similar
> purpose -- <herd/> and <maintainer/>, with <herd/> being less
> descriptive. For this reason, sometimes herd's associated e-mail is
> listed as <maintainer/>, and sometimes even the same thing is listed
> using both tags.

Herds are groups of people that the Gentoo Project knows about. There
may be other aliases, but these particular ones are bound to a
@gentoo.org alias. That is what the <herd> tags convey. In April 2008 we
came to some sort of agreement about the way bugs are assigned (first
<maintainer> is assignee, rest is CC'd, first <herd> is assignee when
no <maintainer> is mentioned) and that works quite well (especially
because the assignee is now not the person "blamed" for a bug report).

A <herd> is a group of people, and a <maintainer> is not. If a new
developer Devon comes along and is allowed to choose a nick like
"gentoo-devs" (he considers himself a member of "Gentoo" (wat?) and
"Devs" is what everyone already calls him), then the difference in
tags should make a clear distinction:

<herd>gentoo-devs</herd> <!-- This is a group of people -->
<maintainer><email>gentoo-devs</email></maintainer> <!-- This speaks
for itself -->

If there is any lack of clarity here, herd members should clear up which
is which.

As the way <herd> and <maintainer> tags are listed in metadata.xml is
important, people have got creative with that format, and that's how we
ended up reading this thread. We could change that first, and simply
change the rules for bug assignment:

1) First <herd> or <maintainer> is the Assignee.
2) The rest is CC'd.

People will still insist on adding comments and attributes that state
exceptions, but that's fine.

> 2. The common use of <herd/> and <maintainer/> thingies forces
> a particular maintainership model. In particular, we always assume
> <maintainer/> comes first, and <herd/> serves as a backup. You can't
> properly say otherwise using both tags.

How is that an inconvenience (since it is done consistently)? It's
good to know whether you are addressing a single individual or a group.
Conversely it is already good practice to not post to mailing lists and
use the bug tracker in the name of a whole team (there have been
instances where someone was accidentally logged in under a herd title -
that's a bad thing).

> 3. The project member and herd member lists are constantly outdated.
> In fact, most of the herds don't even list members -- just point out
> to outdated project pages :).

So these should be automagically updated to reflect the alias' list of
real e-mail addresses? Sure, it's inconvenient the way it is now (and
has been for years), but that doesn't mean we should drop herds
altogether.

> 4. The whole indirection is just irritating. You can't assign a bug
> using metadata.xml without fetching herds.xml that's in a different
> CVS repo.

I seem to recall lamenting the lack of a proper link between the two
years ago, arguing that either a) bugzilla should automatically expand
<herd> with @gentoo.org (which fails when projects inexplicably choose
username strings that are different from the respective <herd> strings),
or that b) in metadata.xml the full e-mail address should be used
instead of a keyword that needs to be looked up.

> What do you think?

Right now, CC'ing a single alias is inconvenient, but under your
proposal, you might need to CC a dozen or more people instead of that
alias.

Herd aliases (and e-mail aliases in general) are convenient in that you
don't need to constantly update who is CC'd on mail and bugzilla. You
haven't shown a convenient alternative for that.

If herds are just that - aliases - and nothing more, then I say we keep
them and fix the indirection in <herd> <=> alias instead of dropping
the whole concept.


        jer

Reply via email to