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 41FCC138334 for ; Thu, 4 Oct 2018 16:17:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E4646E083E; Thu, 4 Oct 2018 16:17:53 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9A7D7E083E for ; Thu, 4 Oct 2018 16:17:53 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 120B4335C9F; Thu, 4 Oct 2018 16:17:50 +0000 (UTC) Message-ID: <1538669867.2003.7.camel@gentoo.org> Subject: Re: [gentoo-nfp] Please vote on this proposal related to http://bugs.gentoo.org/667602 From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-nfp@lists.gentoo.org Date: Thu, 04 Oct 2018 18:17:47 +0200 In-Reply-To: References: Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-fMqqrT0Py6/Jma+Eu4cn" X-Mailer: Evolution 3.26.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-nfp@lists.gentoo.org Reply-To: gentoo-nfp@lists.gentoo.org Mime-Version: 1.0 X-Archives-Salt: 348a481d-93c5-4c8a-a5e4-edaac022c45d X-Archives-Hash: 83f38f1ef7e4189a9a285f20ab86318e --=-fMqqrT0Py6/Jma+Eu4cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2018-10-04 at 11:14 -0400, Alec Warner wrote: > Summary: > The short version of the bug is that a non-trivial number of developers > cannot commit with an SoB line because their company has not yet reviewed > the new Gentoo Copyright GLEP, and so they lack company approval to attac= h > SoB lines or agree to the DCO. >=20 > The bug requests that a reprieve be granted until the company reviews the > new policy and (hopefully) grants approval. This would be in the form of = an > allowlist where specific identities (approved by some delegate of council > && trustees) do not require an SoB line to commit for some period of time= . Don't you think that requiring approval for allowlist means double standards? I mean, even if you assume that all requests would be granted, the requirement of approval provides for this 'delegate' selecting which developers are granted this privilege and which are not. In other words, I would rather suggest that the reprieve is granted for everyone and that the allowlist is maintained by Infra as part of opt- out hook intended to avoid developers accidentally missing the tag. > Proposal: > I propose the board grant this reprieve, for whitelisted accounts for 90 > days, with no extension. Williamh will supply the initial list of account= s, > to be reviewed verbally by a board delegate and a council delegate. >=20 > If the company cannot return a decision in 90 days, we can revisit the > motion with any updated data. I'm confused. This really reads like 'no extension; except we will vote on extension if necessary'. > If the company returns a decision before 90 days, the whitelist program > will be terminated (regardless of decision reached.) Note that if the > company decides that approval will not be granted, we will in effect be > unable to accept commits from these developers on work time. Does this imply the reprieve will be granted only to the employees of one particular company, or will it extend to all developers in similar situation? In the latter case, will the decision of one company affect the status of the reprieve for other developers? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-fMqqrT0Py6/Jma+Eu4cn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlu2PStfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQrcwg//UzbsiYfX9tqh/RLvwefzbjFSD7qFHZiuC3Nw0bD1FZ90WfWD9nXsDub5 t1u/FF+GxSOduXwbSO5NiR8sqL1Tmp5UwKftxsokDFOP2wmwL8YDz9EEnO51Lana xqOrVw9hFgFfWl4Oj7NvApswLgwAE8bj6ggytAucQEA9nNiIUWW7vhYXxI0znhf8 0UsWweu7aU1ywzQ6FfKKld1dLBpRq4UA2fBUTzxEf2NgUYiZfS7gwzma1ju9eD8j 8HwieFk6GwKHsNeMm8mKNeAjl3/msFhQqgnWNCAV/IkoGaRlfHXGwFeQol4MXkiH hfPdW81E8pj1IDNbACdpmSL/D7+scbwxnIEuAZX2JBdnlpF61KE2GHb4GFLQZ4lG mGQzo89QorXiqTI+LoxY9/gR0hmlLBW5Bcj1cxhI+OvF1kU2OtM4p9/Us8hisW2Y ZXTuZhhm0pP/PpNPLV5wTXux0mVJQeOBeiE5dUubKmIcwQaIsyT7D0ZVg1m6dp+h wYvdIN75f5PSzD0zHWlqKamX1X5nNplENUQAzVxu0vFNBcRSBX+77jN+DvGRU4LU CxpGzI2Goy7GrC3g8j94xNbpb+qvNdOd4KgoXSHs5QbNExiIU9Ib5smgJZOnhuXH ZaQ4YnMaJTKM4yqkyck1x6JaJmrInqtXmUB85HddhmwHAf0pAd8= =ugc4 -----END PGP SIGNATURE----- --=-fMqqrT0Py6/Jma+Eu4cn--