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 4B683138334 for ; Tue, 10 Dec 2019 05:44:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8DAA1E0977; Tue, 10 Dec 2019 05:44:47 +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 328DFE0953 for ; Tue, 10 Dec 2019 05:44:47 +0000 (UTC) Received: from [10.33.38.94] (unknown [83.145.195.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: juippis) by smtp.gentoo.org (Postfix) with ESMTPSA id 363DD34D8B2 for ; Tue, 10 Dec 2019 05:44:43 +0000 (UTC) Subject: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing) To: gentoo-dev@lists.gentoo.org References: <84a435bffe460efd2620ceec0c0405fa18a7937b.camel@gentoo.org> From: Joonas Niilola Message-ID: <6f1dc9b3-e13e-1186-f75a-51615db505d3@gentoo.org> Date: Tue, 10 Dec 2019 07:44:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 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 In-Reply-To: <84a435bffe460efd2620ceec0c0405fa18a7937b.camel@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="c6iOvWlKHGwKE4MzLr91gwtw23o7ERRIy" X-Archives-Salt: 881db550-1dd5-4c46-a44f-dbc658958629 X-Archives-Hash: 9538645c190d427d30eee58b04d00a17 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c6iOvWlKHGwKE4MzLr91gwtw23o7ERRIy Content-Type: multipart/mixed; boundary="csrYfwAZC6IlccbxX50nckCUOEy2ALWmK" --csrYfwAZC6IlccbxX50nckCUOEy2ALWmK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hey, On 12/9/19 10:17 AM, Micha=C5=82 G=C3=B3rny wrote: > Hello, > > I think the policies proposed in GLEP 81 [1] were overenthusiastic > and they don't stand collision with sad Gentoo developer reality.=20 > Instead of improving the quality of resulting packages, they rather > hamper their adoption and cause growing frustration. > > The problems I see today are: > > > 2. Mailing list reviews don't serve their original purpose. > > The original purpose of mailing list reviews was to verify that > the developers use new packages correctly. For example, Michael > Orlitzky has found a lot of unnecessary home directories specified. > Of course, that works only if people submit *ebuilds* for review. > > However, at some points developers arbitrarily decided to send only > numbers for review. This defeats the purpose of the review in the firs= t > place. The problem: There is still no any official documentation about using acct-, and reviewing it was/is pretty much left on the shoulders of one man. It's easy to say on hindsight it was implemented too quickly. > > > 4. Assignment mechanism is not collision-prone. > > The secondary goal of mailing list reviews is to prevent UID/GID > collisions. Sadly, it doesn't work there either. Sometimes two people= > request the same UID/GID, and only sometimes somebody else notices. > In the end, people have hard time figuring out which number is the 'nex= t > free', sometimes they discover the number's been taken when somebody > else commits it first. If I remember correctly, at one point it was agreed not to paste ebuilds because they all just looked similar, but just ask for IDs? > > > All that considered, I'd like to open discussion how we could improve > things. > > My proposal would be to: > > a. split the UID/GID range into 'high' (app) and 'low' (system) > assignments, 'high' being >=3D100 and 'low' <100 (matching Apache suEXE= C > defaults), > > b. UIDs/GIDs in the 'high' range can be taken arbitrarily (recommending= > taking highest free), while in the 'low' range must be approved by QA, > > c. no review requirement for the 'high' range, just choose your UID/GID= > straight of uid-gid.txt and commit it, > > d. strong recommendation to use matching UID/GID for the same user/grou= p > name. > > WDYT? > > > [1] https://www.gentoo.org/glep/glep-0081.html I think none of the above really prevent collisions for unmotivated people. They also still require manual update of uid-gid.txt, and it can't be expected everyone does it. Now this is not of a big interest to devs, but I believe committing non-dev acct's will get hard here, because there might be some "lag" with their contributions vrt. the current situation. Honestly I'd say just put -1 on all acct- packages then let sys admins modify them locally to whatever they need. I feel like this whole GLEP just serves the minority while making many other contributors uneasy. -- juippis --csrYfwAZC6IlccbxX50nckCUOEy2ALWmK-- --c6iOvWlKHGwKE4MzLr91gwtw23o7ERRIy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGnBAEBCgCRFiEEltRJ9L6XRmDQCngHc4OUK43AaWIFAl3vMMRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 RDQ0OUY0QkU5NzQ2NjBEMDBBNzgwNzczODM5NDJCOERDMDY5NjITHGp1aXBwaXNA Z2VudG9vLm9yZwAKCRBzg5QrjcBpYmM2CACx2iakBRfwIUXryVaFEosrAjYmymsu Q9gMvUrX5fOYuPa7PQ7Q5j01Zf7Hi1s5ye5win9r2gAt2BePYBwkSyddCNss6/VG HYtp6V2JNTAeG1cmQ4bEkWykUg/+m1C+oyViaxmRSoEcAUqC7s3fupmzGh14PzOk RiLAzsxIW5Qpyj+s+wdRqfKYEgM9bTVoY7aLcmikCdhZUMrHROhgFMtTf4FWG1Ya PRECIdDV+vyTeOjN8sk/gUb/kBnr4x1XDllRxdE4PS/JzkuX5V4qsVFuPMIxcXTp Kwx++Ncebo80ckAspJmUMbEaRHuq7fUQjvPw06BLR7hsktiANFKl09Nq =yVGG -----END PGP SIGNATURE----- --c6iOvWlKHGwKE4MzLr91gwtw23o7ERRIy--