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 E8111138334 for ; Tue, 10 Dec 2019 16:17:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A679FE09ED; Tue, 10 Dec 2019 16:17:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 D5BC0E09D4 for ; Tue, 10 Dec 2019 16:17:31 +0000 (UTC) Received: from pomiot (c134-66.icpnet.pl [85.221.134.66]) (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 2C8D434D91E; Tue, 10 Dec 2019 16:17:30 +0000 (UTC) Message-ID: <5ee5ff2e8c705a3a5876d3e46af06be8e1462953.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing) From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Tue, 10 Dec 2019 17:17:25 +0100 In-Reply-To: <4b4c78ba-e28c-fd74-7a50-10ee0facac9b@gentoo.org> References: <84a435bffe460efd2620ceec0c0405fa18a7937b.camel@gentoo.org> <6f1dc9b3-e13e-1186-f75a-51615db505d3@gentoo.org> <4b4c78ba-e28c-fd74-7a50-10ee0facac9b@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-rddJuFA3ATsJlOmxkd31" User-Agent: Evolution 3.32.4 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: ea0bad4b-bf63-4477-bc95-b6910ba2f102 X-Archives-Hash: 0806099c15675aaf7a32b07a4c506cd9 --=-rddJuFA3ATsJlOmxkd31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2019-12-10 at 18:13 +0200, Joonas Niilola wrote: > On 12/10/19 3:34 PM, Micha=C5=82 G=C3=B3rny wrote: > > > The problem: There is still no any official documentation about using > > > acct-, and reviewing it was/is pretty much left on the shoulders of o= ne > > > man. It's easy to say on hindsight it was implemented too quickly. > > There is official documentation in devmanual [1]. >=20 > The _detailed_ one was pushed 2 hours before I made my post, if that's > what you're referencing now. >=20 > https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=3D9613e9e69ae16e6= 981f90135f92811ded641b52c >=20 > How could I have missed it? But yes, it's exactly and finally what was > needed for a long time. No, I was referring to the short one. But yes, this one is better. >=20 >=20 > > Hence my idea that if we stop requiring mailing list RFC, we can replac= e > > that with obligatory update to uid-gid.txt. It should work good enough > > for synchronization. >=20 > Mmm, yeah sure, I guess it works better for everyone. I can still > imagine someone pushing acct- ebuilds with colliding UIDs, but at least > the CI checks for duplicates right? So committer should receive a mail > to change their numbers ASAP right? Yes. > While at least with mailing list RFC > there's a small chance it can be prevented (like was done twice last > week), but the process is indeed more annoying and more manual. >=20 I wouldn't really call it 'prevented'. Sure, somebody caught it in time, and the other party noticed it in time. However, if we remove the waiting period related to reviews, the risk of collision is much smaller. That said, I need to add some pkgchecks for missync between uid-gid.txt and acct-* packages. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-rddJuFA3ATsJlOmxkd31 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl3vxRZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA6HIgf/Tgr27BJ64qRdluc4qYs+IhzmPbMaPjcfloirS45uwHHSNGl1gIn2G2AM +b1z3hKzJE0gHEuxEI/K13n/6UUDcwbfssv8pDAqiwAzH1wiVkUgL2UeyI2TC1hx vo1ADwdGyWWOtbfdu0EpieV49kR7yMDatp8bfyZgOuctD/S4zvPAdy95xyTv5H2d oRoh1BvI7GGjtWAVOMCft8AWqpFsDMffvX1UJhR1x7EkwkLdiuyY8M+CpJjb8gD3 4P1AQQzgRq//OcvIbrLZ/e2qk3RlVHKiBC/g61mXr4Xq0jvdZxODyJ4+uzHTP/oO g26SyAwVfjG19Dv9pU0gOnlB5r0KJw== =aCdk -----END PGP SIGNATURE----- --=-rddJuFA3ATsJlOmxkd31--