[gentoo-dev] About net-p2p herd status

[gentoo-dev] About net-p2p herd status

[Pacho Ramos]

Hello

Looks like this herd has some unattended bug for a long time (some for
some years), and looks not quite active. Is it still active? Should it
be dropped in favor of dedicated maintainers for its packages?

Thanks

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

[Samuli Suominen]

On 31/03/13 17:14, Pacho Ramos wrote:
> Hello
>
> Looks like this herd has some unattended bug for a long time (some for
> some years), and looks not quite active. Is it still active? Should it
> be dropped in favor of dedicated maintainers for its packages?
>
> Thanks
>

I've just added myself back to net-p2p@ but haven't had time to work on 
many bugs yet

But no comment, if the herd gets deleted, then it gets deleted, i'm 
neutral about that, can't speak for others

- Samuli

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

[Markos Chandras]

On 31 March 2013 15:32, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 31/03/13 17:14, Pacho Ramos wrote:
>>
>> Hello
>>
>> Looks like this herd has some unattended bug for a long time (some for
>> some years), and looks not quite active. Is it still active? Should it
>> be dropped in favor of dedicated maintainers for its packages?
>>
>> Thanks
>>
>
> I've just added myself back to net-p2p@ but haven't had time to work on many
> bugs yet
>
> But no comment, if the herd gets deleted, then it gets deleted, i'm neutral
> about that, can't speak for others
>
> - Samuli
>

The herd currently maintains 58[1] packages and a number of them are
being co-maintained by other people.
I don't think the herd is active and my opinion is to move
high-profile packages, such as deluge, qbittorrent, rb_littorrent and
packages co-maintained by others away from this herd.

[1]
hwoarang@helix ~ $ portageq --herd=net-p2p -n | wc -l
58

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

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

[Rich Freeman]

On Sun, Mar 31, 2013 at 10:59 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> The herd currently maintains 58[1] packages and a number of them are
> being co-maintained by other people.
> I don't think the herd is active and my opinion is to move
> high-profile packages, such as deluge, qbittorrent, rb_littorrent and
> packages co-maintained by others away from this herd.

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.

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

Rich

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

[Tom Wijsman]

[-- 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 --]

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

[Rich Freeman]

On Mon, Apr 1, 2013 at 7:41 AM, Tom Wijsman <TomWij@gentoo.org> 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

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

[Tom Wijsman]

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

On Mon, 1 Apr 2013 09:57:05 -0400
Rich Freeman <rich0@gentoo.org> 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@gentoo.org/

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@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 --]

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

[Markos Chandras]

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

No need to. If a herd becomes inactive we either call for help or remove it.
We have already done this many times and it works just fine

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang