Re: [gentoo-dev] Re: About net-p2p herd status

[Rich Freeman]

On Mon, Apr 1, 2013 at 7:41 AM, Tom Wijsman <TomWij@g.o> wrote:
> 1. Get more people to join these herds (devs, future recruits, ...)
>    and set up project, leads and proper organization. This is the least
>    confusing approach; since the same work is done but just by more
>    people, which tackles the communication and workload problems.
>

Sure, non-controversial IF there is interest.


> 2. Combine multiple herds in one bigger "network" herd. If we can't
>    just magically get more developers to join these herds, we could put
>    all the developers from these herds in one bigger herd to force them
>    to organize and communicate. Get one bigger group to pay attention
>    to the bugs, without caring whether there is a personal interest or
>    not; when you are interested in networking, there should be no
>    problem to occasionally deal with another package as well.
>

I REALLY don't think this is a good idea.  You might as just have one
big herd and call it "maintainer-wanted" or even "gentoo."

Individual devs work because there is somebody who is accountable for
keeping at least a reasonable level of quality, and their pride is
likely to spur them on to take care of the package.

Active herds work because there is a team with a leader who
collectively don't want to look bad when things aren't working.  The
herd could have a large or small project team looking after it - it
just matters that they care.

When you lump a bunch of stuff into a big amorphous blob and put 47
people in charge of it, then nobody really cares about anything.  It
just results in 47 people with bugzilla in their killfile.

I suspect that the only reason some devs are listed in herds that
appear inactive is that at some point in time they were the sole
maintainer of a single package they actually cared about, and somebody
decided to put that package in a herd, and then the dev got added  to
the alias so that they were still "allowed" to maintain it (or some
variation on that theme).  The dev really could care less about the
other 47 packages in the herd.

Devs should really review the aliases they are attached to and edit
for relevance.  That said, sometimes there is a need to belong to an
alias even if a dev only contributes to a narrow scope of work.  It
isn't a problem as long as the team is active in general.

> 3. The one you suggest, which would be the approach to go for if
>    it is unreasonable to salvage the network herd(s). The problem here
>    is that you don't know in advance what will happen with the
>    packages; this may yield a lot of unmaintained packages that are
>    later dropped from the tree while they work just fine.
>

If no herd forms, the list of affected packages should be announced,
and if nobody adds themselves to the metadata within n days they go to
maintainer-needed.

As I've stated before maintainer-needed packages should only be
treecleaned if they are, in fact, broken (a few debatable cases have
come up, but for the most part this is what happens).  A few bugs that
don't impact most users in a serious way should not be grounds for
removal.  However, if the package has a blocker or serious quality
issue then it should be removed.  Things won't get any better by
listing an email address that nobody follows in the metadata (an email
that 50 people get and all ignore is no better).

As far as improving manpower and such - I think everybody is
supportive of this.  However, it is important that Gentoo not be held
back by not wanting to break packages that aren't maintained -
otherwise it will become irrelevant.  Proxy maintenance is better
supported now than it ever has been in the past, so if people want to
step up without having to become devs they should do so.

Rich