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 59404138330 for ; Fri, 7 Oct 2016 15:22:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EBAD1E0C18; Fri, 7 Oct 2016 15:22:30 +0000 (UTC) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (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 AC065E0C17 for ; Fri, 7 Oct 2016 15:22:30 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ry6so24064881pac.3 for ; Fri, 07 Oct 2016 08:22:30 -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=MfUN83afmq1gZf+N9N/0tvJyKGYVVYlE/6Ak1IhRrhI=; b=0oQ0zOJSERyx1IRZVrP5V+9w9LUJYT38oODis87OR2zxJ0D6tKFd8WuFeZPrkukzl2 Y5CgL+45s32rLpxEeMKKG454fng0QYrmB5WYThDbwYKD53LE9BEOKsTLz+r5rsFAlUXy jVui8R0lpYAArKQYUwC1DLtAU5UkyzZzFG1xnAhXACjIZOrhTj8UVXEt6PImV4dDQm22 OAfXNRAZ0xx+o5n80BKT//M8jGyQ2OeGYfgtqxepl+FCkGZdc2ncIjiHnOyZVOLTyi/w LJF18Ux4BVHxXB5zag8l8ppFrz2RvXES1M9Rt3az4ZAg1I/5QW1IM3TDG3wP4djRssfS MjBA== 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=MfUN83afmq1gZf+N9N/0tvJyKGYVVYlE/6Ak1IhRrhI=; b=ZVq52Ee8wqQC8WKE4R7Wt5fgzysyLmPjls/C3yzOL+5JY2pc1Shu+mWCnD55gL6PE8 +h4cKRa/3ITSLS+LEaYD6hwwQn44o57408hsEjir/B7GCoWzChXVVfVxLLsurAGkCmt8 GD8ROTBUX5otwcT5Y4ZrBPwcmtlMPJ9zR4hV37cKhERU1nEmHxBRPJc1o+8Z9t4jf7MR c3kZ6R7n2k45vW6n+aezfPsf1LAwzSpjpRYZHochvwzakKz1WJPwPImFYZlp9yn/2Qit H5EtoqKLfiPszW4i0O/WmNdCx1DH0u0OeNhcu9GzgGQO9i+J6tNwMPRCZqzyCOLYdvsh E5vg== X-Gm-Message-State: AA6/9RljbGpbhvz5r5t4tXLSN32543sR222qBqlLNJjYK9F0JQCkjk/jIVeaPEy8dZvoFA== X-Received: by 10.66.132.40 with SMTP id or8mr31307367pab.123.1475853749447; Fri, 07 Oct 2016 08:22:29 -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 p26sm14816133pfj.80.2016.10.07.08.22.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Oct 2016 08:22:28 -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: <888704f7-5a9d-650b-91c6-52063bc814d9@gmail.com> Date: Fri, 7 Oct 2016 08:22:27 -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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ea0ntjkCqHgINpdDHl9xbThNWMDUBv7x9" X-Archives-Salt: 51312d90-3a00-487d-9f33-fc181264ccc7 X-Archives-Hash: 9b8159ba7a92c21dfd0ca260f04a3f90 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ea0ntjkCqHgINpdDHl9xbThNWMDUBv7x9 Content-Type: multipart/mixed; boundary="A0Xjp7b5GdcWp5Oe4FojcII26XfRp3WER" From: Nick Vinson To: gentoo-project@lists.gentoo.org Message-ID: <888704f7-5a9d-650b-91c6-52063bc814d9@gmail.com> 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: --A0Xjp7b5GdcWp5Oe4FojcII26XfRp3WER Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/07/2016 08:13 AM, Rich Freeman wrote: > On Fri, Oct 7, 2016 at 10:54 AM, Nick Vinson wro= te: >> >> 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 a= lso >>>>> 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 ba= ck >>>> in if the bug isn't closed before some deadline. >>> >>> What I want to prevent is a stagnation where a dev gets mistakenly >>> locked out because his case got left in limbo. >>> >>>>> 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. >>> >>>> Sure, if all three of your preconditions are true I agree with your >>>> conclusion. However, if comrel screwed up and there was a mistake a= nd >>>> the developer is actually still a problem, then the solution is to f= ix >>>> the mistakes, not keep them around. >>> >>> And how do you know whether the developer is a problem or not? >=20 > The same way Comrel knows. You look at the evidence and draw a > conclusion. If you don't trust somebody to do that, you shouldn't be > putting them on the Council. >=20 >> >> 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. >=20 > And what happens when somebody sues Gentoo or one of its contributors > for not doing enough to deal with a problem, because we're fighting > over process when there is agreement that the person in question ought > to go?=20 The same thing that happens when somebody sues Gentoo or one of its contributors for discrimination or some other related charge because it overreacted to a problem and punished an innocent developer. That said, if there are concerns about legal issues relating to Gentoo policy or procedures, then the Trustees need to be notified so they can look into it. Neither the council nor ComRel are staffed with the expectation to understand or act on potential legal issues. The Trustees, on the other hand, are expected to address legal concerns in whatever manner is appropriate. They are the ones, after-all, that would have to deal with any lawsuit against the Gentoo foundation. >=20 >> 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. >=20 > This would only be a valid criticism if every complaint resolved in > the harshest possible punishment. From the sound of things most > complaints result in no action at all. As far as I can tell most > Comrel actions aren't even appealed. After all, the matter that > started this whole discussion wasn't even appealed to the whole of > Comrel let alone to the Council. >=20 --A0Xjp7b5GdcWp5Oe4FojcII26XfRp3WER-- --ea0ntjkCqHgINpdDHl9xbThNWMDUBv7x9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJX972zAAoJEAQpRPZaa5gqMqQQAJGAodJjuPpXHCTOXDYzo9RN /WnIr0chOwrEOYJiahcAqx4cu7Cdg/O9fFfbSPIkb23h1NlAG74V9E+5uOAaa0dn SFTp6uSE0OnyZJjYBercOkuVv7+0Jyqy7CQC06kM1h59KRoY92tTnT6BhAoCyHPS Tk4eAI+X48QdAmIGLRfW+yU6TB/S3cm2QHPc+46Q4PK2QH2DVYZyKLvqs3uDUdGA TeocH6G+fWn6pvlv6qQxuj1l5NuFb7I/7wNR6zdEcFf5laZOTEeFfJ7ykzKe16zQ wcw21ibSEBfvmdTzbX8CVV7ZR3Y8Rv8cmlrLF8wyRpJPfzEBvgWcCI9uiNYL+iDg jAx7wlHKASRUQk53gKLvnaLp1kdvPB9OzgEtIrXk5D5XoQVBGwflkp5mBYD2AxWX ts6AZqLnzfv2IJHpPnYCBttiSTU0TI8ssFYLEo2ALN3NPazAOGkC6OAKBWh1LZRr OoEf5URRGU4Ivo2MScjo3yYZaU8IrZgsawZTp0rPJCJ37WF4lOBf7Ank3Gz4vxjc HzDC9elJU784f86vCX8/Vx1JOBD8JJoDSGICfxE4Nd8mbhWMVwSxQMPme2LVE2KX CxagsoaheGxm7+kMfwvYGnEt5igV6+2xMmPQZRU9dM4QMhGIdIogXjTW26r9vrGg jvtjidivlGKcN653Xwra =OG0r -----END PGP SIGNATURE----- --ea0ntjkCqHgINpdDHl9xbThNWMDUBv7x9--