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

[Tom Wijsman]

On Sat, 27 Sep 2014 18:45:12 -0400
Rich Freeman <rich0@g.o> wrote:

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

Knowledge codification is nice; otherwise, this is just-another-thread.

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

Looking at a blank slate hides the origin of these ways.

Aliases set up mails on the infrastructure. Herds assign multiple
relevant maintainers to multiple packages. Projects are a need for
serious organization.

This is what we have ended up with starting from that blank slate.
 
> 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.

Aliases are there to support herds or projects, it shouldn't be seen as
a separate way to group people. The other groups are straight froward;
herds for groups that maintains packages, projects for groups that take
on a serious project. Projects that take on packages have created herds
(eg. proxy-maintainers, ...); so, this is or can be consistent.

> We have inactive examples of all three.

Yes, they capture inactivity; iotw, what's in a herd/project name? :)

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

If read and compared correctly, the origin paragraph is a TL;DR to this.

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

+1, as some of us revealed; but note that projects can also hide
abandoned efforts, eg. the Council recently cleaning old dead projects.

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

There are projects which haven't selected a new lead for years ...

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

... thus it only works when some entity external to the project forces
new lead elections; as otherwise, projects have no such $1 ping-pong.

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

Unnecessary stuff: Organization, knowledge codification, time, work, ...

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

It made sense to me from day #1 of contributing to Gentoo; it surprises
me that this all of the sudden is assumed to be a problem, it makes me
rather skeptic about whether a structure change is needed.

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

That would be nice.