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

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5235 bytes --]

On Mon, 1 Apr 2013 06:33:54 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> I think that herds really only make sense if there is some kind of
> coordinated team effort behind them.  Otherwise they're little more
> than another form of category and a black hole for bugs to go into.

Let's see, some euscan / b.g.o / eix magic yields us:

net-dialup: pinkbyte, sbriesen
    Listed as herd for 60 packages, category of 57 packages.
    Assignee for 58 open bugs, category of 77 open bugs.
    Almost half of the bugs were not changed for a year.

net-fs: vapier
    Listed as herd for 20 packages, category of 19 packages.
    Assignee for 52 open bugs, category of 91 open bugs.
    Maybe a large amount of bugs for a single person?

net-ftp: polynomial-c, voyageur
    Listed as herd for 6 packages, category of 29 packages.
    Assignee for 3 open bugs, category of 48 open bugs.
    Seems this herd deals with a rather small amount of packages, though
    there are still some bugs open for the category.

net-im: chainsaw
    Listed as herd for 58 packages, category of 77 packages.
    Assignee for 47 open bugs, category of 130 open bugs.
    Maybe a large amount of packages and bugs for a single person?

net-irc: binki, gurligebis, jdhore
    Listed as herd for 63 packages, category of 71 packages.
    Assignee for 34 open bugs, category of 81 open bugs.
    The extra workload is covered by the third person, is it enough?

net-mail: eras, hattya, radhermit, robbat2
    Listed as herd for 186 packages, category of 106 packages.
    Assignee for 80 open bugs, category of 118 open bugs.
    The extra workload is covered by the fourth person, is it enough?
    Compared to net-irc, there are much more bugs open here; maybe
    there are slightly too much packages covered?

net-news: kensington
    Listed as herd for 21 packages, category of 15 packages.
    Assignee for 7 open bugs, category of 10 open bugs.
    This one is reasonable, but should a single person be a herd?

net-p2p: armin76, sochotnicky, ssuominen
    Listed as herd for 67 packages, category of 66 packages.
    Assignee for 80 open bugs, category of 119 open bugs.
    Considering how empty the herd was before, this was painful.

net-proxy: TomWij, dastergon
    Listed as herd for 30 packages, category of 38 packages.
    Assignee for 25 open bugs, category of 52 open bugs.
    Might be reasonable, though we need to act / coordinate more.

netmon: cedk, constanze, jer, pinkbyte, radhermit, vapier, zerochaos
    Listed as herd for 251 packages.
    Assignee for 106 open bugs.
    This army should be able to deal with it, I assume they coordinate
    it. More than half of them are active on a day to day basis, there
    is certainly no issue with this herd.

So, the majority of network herds seem to just be overworked.

> Certainly a few herds are active in this way, but it seems like the
> majority are not.  Where they are not we should get rid of them,
> unless a team steps up to actively maintain them (defining a project,
> electing leads, etc).

As you can see, most of the network herds I listed here follow this
kind of trend. There are three options that I see:

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.

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.

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.

Regardless of the option picked; the main problem is lack of manpower.

Maybe we could work on methods to find more interested recruits and
enlarging the recruiting team, a different approach to committing where
we put the users central instead of the Gentoo Developers (a pull
request system like GitHub / BitBucket / ...) kind of like Sunrise or
maybe something completely different...

The other way to see this problem is a flood of network packages, but
I think having more packages is a good thing; it makes Gentoo Linux
useful more a lager audience. Though, overlays achieve this as well;
but are overlays really the right approach to solve a lack of manpower?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]