Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Sat, Sep 27, 2014 at 6:13 PM, Tom Wijsman <TomWij@g.o> wrote:
> The question becomes "does every herd want to become a (sub)project?".
>

So, there was some discussion on -dev, apparently some discussion I
wasn't a part of, and some that I was (such is the nature of IRC).

I think it would make sense to take a step back and ask what we'd do
if we were starting with a blank slate.  Aliases, herds, and projects
are all ways of grouping people, but they are used in different ways,
sometimes.

My real problem with herds isn't the idea of having more than one way
to group people.  My real issue is that we have several ways of
grouping people and no consistent way of doing so.  You have to look
in different places to find out who is on an alias/herd/project.  We
have cases where more than one of these are loosely associated, but
membership is inconsistent.  We have inactive examples of all three.

So, let's step back and think about why developers would want to be
part of a group, forget about what we call these groups, and then
figure out what kind of model makes the most sense and how to get
there.  In the final design we might want to not split groupings up
all over the place (wiki vs herds.xml vs alias files that nobody but
devs can read).

So, one level of association might be registering an interest - such
as what is sometimes done with a mail alias.  A developer, or even a
non-developer, might want to be informed about what is going on with a
package or group of packages, but they are not making any kind of
commitment to actually taking care of them.

The opposite would be a project as defined in GLEP 39.  This is a
formal association of developers that elects a lead, and acts as a
unit.  The project could establish policies and it is generally
expected that they be followed (we can escalate to the Council if
there is a problem).  This is especially valuable for core
dependencies like toolchain, frameworks, etc where good planning makes
everybody's lives easier.

Then you have groups of people who sort-of maintain peripheral
packages, which is what I think is what many herds are (but their use
is totally inconsistent, so this isn't true everywhere).  My issue
with this sort of thing is that it is really hard to tell if a package
is actually maintained.  Devs basically drop-in to scratch an itch and
then abandon things.  Emails to aliases get ignored, since nobody in
particular is in charge.

That is my main issue with herds - they're dumping grounds for bugs
that nobody seems to care about, at least in some cases.

With a project you can at least ask "have you selected a lead in the
last year" and get some kind of pulse on activity.  Herds are nice
from the standpoint that they cost nothing to maintain, but that also
means that there is no way to gauge commitment.  Having an election is
a big like some proposals to charge $1 to register a copyright renewal
- it isn't about the cost so much as just making somebody actually do
something to prevent de-listing.

I guess my question is when is something like a herd the best solution
to a problem, and what is that problem?

I don't want to change for the sake of change.  If we stay the same
I'd like it to be because what we're doing actually makes sense.

If we do keep something like herds, I'd still consider some way to
consolidate herd/project membership lists so that tools can scan a
single location.  Whether a group is a herd/project/alias could be an
attribute.  This is no different than not having separate ldap servers
for devs vs staff vs infra, and so on.

--
Rich