From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-89621-garchives=archives.gentoo.org@lists.gentoo.org>
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 2A119138334
for <garchives@archives.gentoo.org>; Mon, 9 Dec 2019 21:48:42 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 315D9E0929;
Mon, 9 Dec 2019 21:48:38 +0000 (UTC)
Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144])
(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 EBA5DE088F
for <gentoo-dev@lists.gentoo.org>; Mon, 9 Dec 2019 21:48:37 +0000 (UTC)
Received: by mail-il1-x144.google.com with SMTP id z12so14146788iln.11
for <gentoo-dev@lists.gentoo.org>; Mon, 09 Dec 2019 13:48:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gentoo-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=H6Yq+b7fACBoPbaxAYGSnifhLNcSlLt33gqjlm9/b74=;
b=uX2T7A7I4gnXFHHSDYjdT7elbCPq8OK/E+6S9i0Y0xIBFwzE48D9+xGgqv/0wYHOGy
qd1kzHi8nrlzTtlzuqUmF6AssGsUqJu9Td6LUnzrQtz/40cbE4AXRw8+WwaAQrare8uk
+4f6zRv+Dmclu5KJnXHJLk0gYjv54+bVpvXd8kbJUNNw/XptmU9bULgjDfehjK0Ba/Qa
3/eFx+11Xxv3ual0LUpJAzC2nYfFq7YOhwBgCjobMY5a+9+4cvHUJ3EbAhlZNP2HFQDk
ORrrshEwZrOT3YhyEHwRRpWd6fdf2DOTI/rHo4tEkS6rhjZwpUSAxo77scH2PfO6bqhm
v9Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=H6Yq+b7fACBoPbaxAYGSnifhLNcSlLt33gqjlm9/b74=;
b=BztPzIGI4CQyCyZmzm0jWk2fOcvHALZ48GfL/VJdsKaV+zHuPmahIzu/7RQfSspmQw
WpXkeRDykLVZAbWagWGZe0w95Kr9mb6TjEjMOiWutEKWvvl5cKVVufLVS37RdIZ9Arht
GGsd9Z9BSVf6BFoH1ENjw50FQdek5IZrTi9HsyefwY82vXrbsXHKyQuKNHiTodhplZpi
nux3sqo0zhNymlxbcxApaaCAhe6sJ43E/0QX2TkYcIwK4yVZI2dpPieK/okfBl0DcwNk
6FhSS3rgnT+hL3IhjPPx/vo4XUgckauFV3n6OOUMJZr8kf17/62Ts1HTtMMILQG4ytf9
eE9w==
X-Gm-Message-State: APjAAAUQAP8qN7l9BMvDvuuhLC4m0/lYlF1jJ98tL3fOUt4PtfWV0MIs
VrX0dDLmRhD6yAShNXetkVMe/y39k1ZPRbJqeUAy9qm0qME=
X-Google-Smtp-Source: APXvYqxkEUsd5gUk2K3egn3fu9Q+v3KvPDqTZCD+N3ldruY31ttxx+7QfvNfzidAyi3t5RJ3X0PeSFhRZvwIK87lp4E=
X-Received: by 2002:a92:8c90:: with SMTP id s16mr31049650ill.38.1575928116426;
Mon, 09 Dec 2019 13:48:36 -0800 (PST)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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
References: <84a435bffe460efd2620ceec0c0405fa18a7937b.camel@gentoo.org>
In-Reply-To: <84a435bffe460efd2620ceec0c0405fa18a7937b.camel@gentoo.org>
From: Alec Warner <antarus@gentoo.org>
Date: Mon, 9 Dec 2019 13:48:25 -0800
Message-ID: <CAAr7Pr9ULsfB-D4navy95JTP_3nB8eD7uo8V5e7z97m4HYaaOA@mail.gmail.com>
Subject: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews,
cross-distro syncing)
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Content-Type: multipart/alternative; boundary="0000000000009250c305994c5bb9"
X-Archives-Salt: 5d9d9d40-74ce-40f5-9fc6-d2701fc371c7
X-Archives-Hash: 62ebfc84225867e8ebcf4e3d7401c401
--0000000000009250c305994c5bb9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2019 at 12:17 AM Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> =
wrote:
> Hello,
>
> I think the policies proposed in GLEP 81 [1] were overenthusiastic
> and they don't stand collision with sad Gentoo developer reality.
> 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.
> 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.
>
What is the mechanism to keep the uid-gid.txt aligned with tree content? is
there a CI check that says I am using the new acct-* eclasses AND I have a
UID / GID assigned that is not matching uid-gid.txt? I see the CI has
"ConflictingAccountIdentifiers", is this already doing this work (checking
that the ebuild matchines uid-gid.txt), or just scanning the whole tree and
ensuring that 2 packages don't re-use the same ID?
-A
>
> d. strong recommendation to use matching UID/GID for the same user/group
> name.
>
> WDYT?
>
>
> [1] https://www.gentoo.org/glep/glep-0081.html
>
> --
> Best regards,
> Micha=C5=82 G=C3=B3rny
>
>
--0000000000009250c305994c5bb9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Dec 9, 2019 at 12:17 AM Micha=
=C5=82 G=C3=B3rny <<a href=3D"mailto:mgorny@gentoo.org">mgorny@gentoo.or=
g</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Hello,<br>
<br>
I think the policies proposed in GLEP 81 [1] were overenthusiastic<br>
and they don't stand collision with sad Gentoo developer reality. <br>
Instead of improving the quality of resulting packages, they rather<br>
hamper their adoption and cause growing frustration.<br>
<br>
The problems I see today are:<br>
<br>
<br>
1. Mailing list reviews hamper the adoption of new user packages.<br>
<br>
Firstly, there are a few developers who obstructively refuse to<br>
communicate with others and especially to use the public mailing lists. <br=
>
While this is a separate problem, and a problem that needs to be<br>
resolved, this GLEP can't resolve it.=C2=A0 Of course, there is no reas=
on to<br>
believe that removing review requirement will actually make them migrate<br=
>
their packages but it's at least one obstacle out of the way.<br>
<br>
Secondly, even developers capable of communication find the two stage<br>
request-wait-commit workflow inconvenient.=C2=A0 At any time, there are<br>
at least a few requests waiting for being committed, possibly with<br>
the developers forgetting about them.<br>
<br>
<br>
2. Mailing list reviews don't serve their original purpose.<br>
<br>
The original purpose of mailing list reviews was to verify that<br>
the developers use new packages correctly.=C2=A0 For example, Michael<br>
Orlitzky has found a lot of unnecessary home directories specified.<br>
Of course, that works only if people submit *ebuilds* for review.<br>
<br>
However, at some points developers arbitrarily decided to send only<br>
numbers for review.=C2=A0 This defeats the purpose of the review in the fir=
st<br>
place.<br>
<br>
<br>
3. Cross-distro syncing has no purpose.<br>
<br>
One of the original ideas was to reuse UID/GID numbers from other<br>
distros when available to improve sync.=C2=A0 However, given the collisions=
<br>
between old Gentoo UIDs and other distros, other distros themselves,<br>
non-overlapping user/group names, etc. there seems to be little reason<br>
to actually do it.=C2=A0 If we even managed some overlap, it would be minim=
al<br>
and quasi-random.<br>
<br>
While other distros provide a cheap way of choosing new UID/GID, it<br>
doesn't seem that many people actually use it.=C2=A0 Then we hit pretty=
<br>
absurd situations when someone chooses one UID/GID, somebody else tells<br>
him to use the one from other distro.<br>
<br>
<br>
4. Assignment mechanism is not collision-prone.<br>
<br>
The secondary goal of mailing list reviews is to prevent UID/GID<br>
collisions.=C2=A0 Sadly, it doesn't work there either.=C2=A0 Sometimes =
two people<br>
request the same UID/GID, and only sometimes somebody else notices.<br>
In the end, people have hard time figuring out which number is the 'nex=
t<br>
free', sometimes they discover the number's been taken when somebod=
y<br>
else commits it first.<br>
<br>
<br>
All that considered, I'd like to open discussion how we could improve<b=
r>
things.<br>
<br>
My proposal would be to:<br>
<br>
a. split the UID/GID range into 'high' (app) and 'low' (sys=
tem)<br>
assignments, 'high' being >=3D100 and 'low' <100 (mat=
ching Apache suEXEC<br>
defaults),<br>
<br>
b. UIDs/GIDs in the 'high' range can be taken arbitrarily (recommen=
ding<br>
taking highest free), while in the 'low' range must be approved by =
QA,<br>
<br>
c. no review requirement for the 'high' range, just choose your UID=
/GID<br>
straight of uid-gid.txt and commit it.<br></blockquote><div><br></div><div>=
What is the mechanism to keep the uid-gid.txt aligned with tree content? is=
there a CI check that says I am using the new acct-* eclasses AND I have a=
UID / GID assigned that is not matching uid-gid.txt? I see the CI has &quo=
t;ConflictingAccountIdentifiers", is this already doing this work (che=
cking that the ebuild matchines uid-gid.txt), or just scanning the whole tr=
ee and ensuring that 2 packages don't re-use the same ID?</div><div><br=
></div><div>-A</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">
<br>
d. strong recommendation to use matching UID/GID for the same user/group<br=
>
name.<br>
<br>
WDYT?<br>
<br>
<br>
[1] <a href=3D"https://www.gentoo.org/glep/glep-0081.html" rel=3D"noreferre=
r" target=3D"_blank">https://www.gentoo.org/glep/glep-0081.html</a><br>
<br>
-- <br>
Best regards,<br>
Micha=C5=82 G=C3=B3rny<br>
<br>
</blockquote></div></div>
--0000000000009250c305994c5bb9--