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

[Tom Wijsman]

On Mon, 1 Apr 2013 09:57:05 -0400
Rich Freeman <rich0@g.o> wrote:

> > 1. Get more people to join these herds (devs, future recruits, ...)
> >    and set up project, leads and proper organization. *snip*
>
> Sure, non-controversial IF there is interest.

Yeah, I know of an user that has interest; but it'll take at least two
months (possibly more) before he can go through recruiting. There may
possibly be more users out there. Interest may not be the problem here.

> > 2. Combine multiple herds in one bigger "network" herd. *snip*
>
> 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."
>
> ...
>
> 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.
>
> ...
>
> 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).

This is an exaggeration, the herd should be kept at a reasonable amount;
we're talking about 19 people here, if you drop those that are just
there for a single package or two you may even drop this to ~10 devs.

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

I don't see why it's impossible for ~10 devs to organize themselves in
a way they care about the packages; the lack of communication also plays
a role in bugs that are left open, bringing small herds together deals
with this as 10 devs are more likely to communicate than 2 devs.

Not that I'm rooting for this, but it's an interesting alternative.

> > 3. The one you suggest. *snip*
>
> 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.

Yes, I know and understand the approach taken. My wonder was rather what
the outcome of this approach would be, but for that I'd need actual
statistics and graphs on how this has happened in the past; basically
the answer to the question: For a given set of packages released to
maintainer-needed, how much other devs pick them up, how many package
end up in proxy-maintainers, how much remain unmaintained, how much end
up treecleaned, ...

It's statistics like these that may help make a more educated choice,
or at least be aware of future problems to deal with as a result of that
choice. We're talking about a few hundred packages, that's a huge list.

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

Ah, while the front page of the TreeCleaner Project seems to indicate
it also happens to unmaintained packages, this is hidden away at the
bottom of the policy. I agree.
 
> 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.

http://euscan.iksaif.net/herds/proxy-maintainers/
http://euscan.iksaif.net/maintainers/maintainer-needed@g.o/

Looking at the packages graphs on euscan at the bottom, it seems that
there are about four times more packages unmaintained compared to
those that are proxy maintained. While it is properly supported, I guess
it needs some more attention in one or another way...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D