From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 23340138330 for ; Fri, 7 Oct 2016 14:54:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 72FABE0AE6; Fri, 7 Oct 2016 14:54:37 +0000 (UTC) Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com [209.85.192.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 37C4EE0AD7 for ; Fri, 7 Oct 2016 14:54:37 +0000 (UTC) Received: by mail-pf0-f182.google.com with SMTP id e6so24674519pfk.1 for ; Fri, 07 Oct 2016 07:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=CfMaff/jmVxNJPyrvYrXluEzZvpt4acZczsCXR0XJdE=; b=APhNb0C4cceOnHhpdQVvE1kCcBWR3T6cRvnSL9RQBy2UveocRPfC9ce/z8asg+MAr2 Bby5rPpb+cK2ErtIpLzW6QZGym8QqgULp4lb3B9TNqb9lKXEkL5VLJsqVYdf5KMaj77E OB1jAihkCPI5XwhsI9+JnkgMlXYJDIe3T3e/iKswS5/tZBFbQXmry8iFCvhppxKHP8bp cP9zQ66wnTi2FLRwVaekcUa86uGgvSjw5kMyEIk+D/jqvcQFeLj/DxgiJ01v8XTuQVCt 5Pgih8HK1puCuTydQT2OXHTS5lq6p0vEpvL0uM5nv2T8ovc0nqXheV+GgtxK+LNfpnmq prIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=CfMaff/jmVxNJPyrvYrXluEzZvpt4acZczsCXR0XJdE=; b=fvjhBnn6IEwLt3+cZUS0AR5ZnU2zW293oS2o69dr96jkudlY0KpI0fPVGO0rZizA2T VkK6MIXRfy1nMjb/YCdCJmKu+otQuhiKN/0ogV8f6xXl/tpi3+ZJSvn4A+Es5RaQOqJu 5UFHQcBk/mm4mjvejp9QCT78hoFt0J7Z5kV561PrkvtGAmuzUrNGq2Jztt3R292NYL2g h51PCp3WqfCjYUM8rcYa8r3zr7krSH/LHw0paIPk9jbw6GPtR3wlrvvp0X1GIYzCvvX8 unb0WjMnsUvueDYy0Y6cqTBOSCcWsmLYCxV+x36J6XOSTTQp3p6+oVjgslnx9zpLsHav wWVg== X-Gm-Message-State: AA6/9RmUUF6Vn24W6Qai4B5f1uyxqkIY6hh8WrzJoQmXjrjN7PfiAl9V93VdZsKWCBCClA== X-Received: by 10.99.3.69 with SMTP id 66mr155890pgd.157.1475852076007; Fri, 07 Oct 2016 07:54:36 -0700 (PDT) Received: from ?IPv6:2601:602:9c00:cf41:a15c:1ca:cdf1:57a3? ([2601:602:9c00:cf41:a15c:1ca:cdf1:57a3]) by smtp.googlemail.com with ESMTPSA id c64sm14699097pfa.0.2016.10.07.07.54.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Oct 2016 07:54:34 -0700 (PDT) Subject: Re: [gentoo-project] Re: Trying to become a Gentoo Developer again spanning 8 years... To: gentoo-project@lists.gentoo.org References: <832d6b86-ee0e-4509-7f74-1e19fd4e4db9@gentoo.org> <46323553-e9c0-8d52-3c2a-a75b0245c7ce@gentoo.org> <1475842976.4388.0@smtp.gmail.com> <1475849132.4388.1@smtp.gmail.com> <1475850760.11751.0@smtp.gmail.com> From: Nick Vinson Message-ID: Date: Fri, 7 Oct 2016 07:54:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <1475850760.11751.0@smtp.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qhVCmD8Pi1GR31ivteCl9hJVs6DshV0RG" X-Archives-Salt: e08274cc-521f-4f55-81ba-1de7bf1cd0b7 X-Archives-Hash: 0dd2d66b7b0b0cde195e3f462f420925 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qhVCmD8Pi1GR31ivteCl9hJVs6DshV0RG Content-Type: multipart/mixed; boundary="3UvjQUf9ftEHp9KpGmsSXd2ru3eo3Ri41" From: Nick Vinson To: gentoo-project@lists.gentoo.org Message-ID: Subject: Re: [gentoo-project] Re: Trying to become a Gentoo Developer again spanning 8 years... References: <832d6b86-ee0e-4509-7f74-1e19fd4e4db9@gentoo.org> <46323553-e9c0-8d52-3c2a-a75b0245c7ce@gentoo.org> <1475842976.4388.0@smtp.gmail.com> <1475849132.4388.1@smtp.gmail.com> <1475850760.11751.0@smtp.gmail.com> In-Reply-To: <1475850760.11751.0@smtp.gmail.com> --3UvjQUf9ftEHp9KpGmsSXd2ru3eo3Ri41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/07/2016 07:32 AM, Raymond Jennings wrote: > On Fri, Oct 7, 2016 at 7:20 AM, Rich Freeman wrote: >> On Fri, Oct 7, 2016 at 10:05 AM, Raymond Jennings = >> wrote: >>> My opinion is that if a developer is bad enough to keep out, its als= o >>> important enough to get the paperwork fixed to prove it. If they >>> have a >>> clean case it *should* be very easy to get the paperwork right. >> >> Sure, by all means leave the bug open until the paperwork is fixed, >> but I don't think that means that the developer should be allowed back= >> in if the bug isn't closed before some deadline. >=20 > What I want to prevent is a stagnation where a dev gets mistakenly > locked out because his case got left in limbo. >=20 >>> But its the "due process" here that proves the developer is bad to >>> begin >>> with. If comrel screwed up and there was a mistake and the >>> developer is >>> actually meritorious, its bad for gentoo to keep them out. >=20 >> Sure, if all three of your preconditions are true I agree with your >> conclusion. However, if comrel screwed up and there was a mistake and= >> the developer is actually still a problem, then the solution is to fix= >> the mistakes, not keep them around. >=20 > And how do you know whether the developer is a problem or not? You don't and I think that's really being overlooked. If ComRel screwed up, then "fixing" the mistake is also reversing their decisions that includes bringing back the dev. If the developer is really a problem, then ComRel will be given repeated chances to deal with the developer and eventually (well hopefully not eventually) the "due process" will be done correctly and the developer will be removed. To me this really seems to follow the line of thinking of "If the dev was really innocent of any wrong doing, no complaint would have been filed". I hope that's not the case because I find that style of logic to be both naive and dangerous. -Nicholas Vinson >=20 >>> Also, I just realized that the "everyone votes" blocks comrel >>> manpower from >>> scaling. >>> >>> What if each member of comrel was granted the discretion to handle >>> everything as they themselves saw fit, subject to the provision that= >>> the >>> comrel lead/comrel as a group/the council could receive appeals? >> >> I tend to agree with this, or a process where Comrel assigns a small >> group of devs to each case. The Comrel lead or maybe the entirety of >> Comrel could keep a general eye on things as a level of QA and there >> would still be Council appeals. I've heard the issue raised that the >> system where all of Comrel deals with every case also causes issues >> when some members of Comrel aren't around or don't have time to deal >> with every case. Basically it makes all of Comrel as fast as its >> slowest member. Imagine if every stablereq required every member of >> an arch team to approve it? It would be like Ago trying to swim with >> concrete shoes. >=20 > And this is exactly why I suggest breaking comrel up into a team of > independent agents overseen by guidelines that preserve uniformity. >=20 > Being geeks we are all probably familiar with the benefits of > parallelization. It's like >=20 > # make comrel -jN >=20 > :) >=20 > And that means comrel shouldn't be drowning in its own red tape. >=20 >> Indeed, with the model where all Comrel members deciding every case >> recruiting more manpower to Comrel would actually have the ironic >> effect of lowering their productivity. The best thing you could do in= >> such a model is instead boot out the slowest contributors. >> >>>> Imagine if stale stablereqs could be appealed >>>> to Council... :) >>> >>> Maybe not stale stablereqs themselves. This is a volunteer project >>> with >>> finite manpower. >>> >>> However, someone deliberately *ignoring* a stablereq when there's a >>> large >>> need for it MIGHT be more worthy of an escalation. But merely being= >>> overworked should not be an offense, and it would probably go >>> through comrel >>> first. >> >> If you punish people for ignoring important bugs at times, then you >> just encourage people to not sign up for the job in the first place. >> If you have a single queue multiple server model (which is how most >> projects tend to work, including arch teams), then the queue only >> stalls if all the servers stall. The solution in this case isn't to >> kick out servers, but rather to encourage more to show up and deal >> with the high priority bugs (the reality is that our servers don't >> strictly work on bugs in priority order, though again I think that >> trying to change this could actually lower throughput). Even if a >> server only closes one bug per year, that still has a net positive >> impact on the queue (assuming zero overhead, which is mostly true for >> the way we work). >=20 > My point is that going after people for deliberately ignoring stablereq= > is *less* stupid than spamming council with appeals on stale stablereq.= >=20 > I never said it was a good idea, just less bad. >=20 > The proper solution would probably be an algorithm that flags the most > urgent stablereq's. >=20 > stablereq triage score =3D age in days * number of reverse deps blocked= on > the stablereq >=20 > Google lives and breathes and eats algorithms, and they even use gentoo= > devs as a recruiting ground (hello recruiters!). >> --=20 >> Rich >> >=20 >=20 --3UvjQUf9ftEHp9KpGmsSXd2ru3eo3Ri41-- --qhVCmD8Pi1GR31ivteCl9hJVs6DshV0RG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJX97cqAAoJEAQpRPZaa5gqGC8P/2u4XPUEbo7sLcreJzyWELvk anw+nbr/aYTXyihzD+IeJk3WJj+hR1ooTPob9ZayolwNQG2/p2K+clYGorjNO7Pv Gu3AsWErcrOwEeBQyBMa7x9yUweLGN+i3T7R+kx4d0OQdscAPVxWWPOvtrvnqP6B 1Kq4FS00Jk3gl31LrhmshMxNlTTHzxcdMLKzUvxhzrdPfek5YTYUcXsxJpO9KXYc 2OkiVAki0CsRWJZIm+usX52ro9algaedeYCKdsLwS9ctxuLlCPmc+ZyIKtUEOP+f dbV2rq5gVMhjjP851tcDcjOQPnU+nvj+WJzvp4pWcsXvAbjhptaJ0WUQd4wT4tba tBaquPql+re4CyhXHhq8loRSjUrhsJyxyZoL8PVXjQFjVSomAf8Irh6icWLDuk49 +M3ZwFbT12kcx/KjMo2bzLteI8SA8IsyBNL7bmbXdxsBpEfQ+AWUimdUkuD4J/gT CDeGoF9IzyL1YiKVdCGH7ewqGEGq3A6feb4Qw3zrhY4qz3XKFDfSKm6fnpqjDRtM dDZTr0Tfqvd8ppQ0/CbspYgE9bMK1hbIigLbcRCqAH1t7qDS+sNhJziSzYqsg451 fn7KkWs1HbLYcDa4Bcfj0kGOm7acUmP0ix0Z5WjoqmPZ8Qhnk4YuOxHlAquUFw81 Blno/dCRtTqpTl8lXal6 =ehri -----END PGP SIGNATURE----- --qhVCmD8Pi1GR31ivteCl9hJVs6DshV0RG--