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 AE59C138334 for ; Mon, 9 Dec 2019 08:17:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 58C55E0841; Mon, 9 Dec 2019 08:17:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.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 00DC9E0805 for ; Mon, 9 Dec 2019 08:17:51 +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 3B93434D77E; Mon, 9 Dec 2019 08:17:50 +0000 (UTC) Message-ID: <84a435bffe460efd2620ceec0c0405fa18a7937b.camel@gentoo.org> Subject: [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 Date: Mon, 09 Dec 2019 09:17:45 +0100 Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-+AMChzyVu0bGMwhFIpZT" 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: 3be0afde-d807-4bb8-83ee-d8cf80ac506b X-Archives-Hash: 9601d9904bf97d88349d41ab7d3a4eb7 --=-+AMChzyVu0bGMwhFIpZT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: 1. Mailing list reviews hamper the adoption of new user packages. Firstly, there are a few developers who obstructively refuse to communicate with others and especially to use the public mailing lists.=20 While this is a separate problem, and a problem that needs to be resolved, this GLEP can't resolve it. Of course, there is no reason to believe that removing review requirement will actually make them migrate their packages but it's at least one obstacle out of the way. Secondly, even developers capable of communication find the two stage request-wait-commit workflow inconvenient. At any time, there are at least a few requests waiting for being committed, possibly with the developers forgetting about them. 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 first place. 3. Cross-distro syncing has no purpose. One of the original ideas was to reuse UID/GID numbers from other distros when available to improve sync. However, given the collisions between old Gentoo UIDs and other distros, other distros themselves, non-overlapping user/group names, etc. there seems to be little reason to actually do it. If we even managed some overlap, it would be minimal and quasi-random. While other distros provide a cheap way of choosing new UID/GID, it doesn't seem that many people actually use it. Then we hit pretty absurd situations when someone chooses one UID/GID, somebody else tells him to use the one from other distro. 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 'next free', sometimes they discover the number's been taken when somebody else commits it first. 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 suEXEC 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/group name. WDYT? [1] https://www.gentoo.org/glep/glep-0081.html --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-+AMChzyVu0bGMwhFIpZT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl3uAypfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA4V9Af+J4ohE5qPndE5e5ykz5SgHCpgvXXNnwZZ8mMigZufc3IAHlPlZgc9osNN ifiQgHq5bCF7lyW6MxuPqh5SsdS0JmMhAtrvaa+gd98FI1p4loky1Jk7k8+z0KZa Q7OnhGtW+5x0lnl3UP8zOzFoiztwz/l/jID3oV2WGP+XV4l6Z1rtS4YsdrIG5uQJ 9/LwA//Z5hDicLrTqrkAEU6q8rS1Ajq/IERciYudRmK+SRdL0fzQVCd5Ir9NOPgv R8fv2C7ELd9y/QukhV1BSIDw28XhbMwxjx7nT+TXPbfXyLVwc1ZlUxStVgav+VPQ zPtWiw4vI6TQcgZx9biUHzUYc3Lufw== =+zoP -----END PGP SIGNATURE----- --=-+AMChzyVu0bGMwhFIpZT--