From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D3DF4138010 for ; Mon, 1 Apr 2013 14:43:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2BA10E0DA2; Mon, 1 Apr 2013 14:43:07 +0000 (UTC) Received: from jacques.telenet-ops.be (jacques.telenet-ops.be [195.130.132.50]) by pigeon.gentoo.org (Postfix) with ESMTP id 4E75CE0D8B for ; Mon, 1 Apr 2013 14:43:05 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by jacques.telenet-ops.be with bizsmtp id Jej31l0112khLEN0Jej31A; Mon, 01 Apr 2013 16:43:04 +0200 Date: Mon, 1 Apr 2013 16:42:14 +0200 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: About net-p2p herd status Message-ID: <20130401164214.2ef6801d@TOMWIJ-GENTOO> In-Reply-To: References: <1364739240.22870.5.camel@belkin4> <515848E7.6070000@gentoo.org> <20130401134137.7acbdade@TOMWIJ-GENTOO> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/I7yC_JeEICE1.s_aMpZ1KtM"; protocol="application/pgp-signature" X-Archives-Salt: bcc24612-b545-4f0b-8a78-4a648dc68c47 X-Archives-Hash: d5bbc297798ebc07da68ecc0d0f39b29 --Sig_/I7yC_JeEICE1.s_aMpZ1KtM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 1 Apr 2013 09:57:05 -0400 Rich Freeman 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." >=20 > ... >=20 > 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. >=20 > 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* >=20 > 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. =20 > 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... --=20 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 --Sig_/I7yC_JeEICE1.s_aMpZ1KtM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJRWZzMAAoJEJWyH81tNOV9ZWAIALzTobbhePqOkdMtejGqWYXD V/Q5BdjarsgB28sgOQqnqB/F6fiXGubWkFHlvUFgLlnpbV9AgVsLTff4HghdDv9K g7FxDKs85IFh6/LB3VYInfwLHAZllDAZ0qLSeeS9IgmqlUpwEtz4jNbcqyKBp9O2 dDfzATqUArj9iahI6LpYmpGZbKmxi31itWkhPazsjdAt6jc/ZMGCu2bwzMWRRD83 +Z/QtkxvVN3HXzAI2PujlBoPAtz1P30UZHTXFXdpnuAQvW5QD//+fKdBf602wcY6 yUOiBsWHdHAJbWj8dskK3nJUXvquRt9s4Szjwh5ME6f8awrivpvoU3edcB9DBOo= =8Osr -----END PGP SIGNATURE----- --Sig_/I7yC_JeEICE1.s_aMpZ1KtM--