Gentoo Archives: gentoo-dev

From: Joonas Niilola <juippis@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)
Date: Tue, 10 Dec 2019 05:44:51
Message-Id: 6f1dc9b3-e13e-1186-f75a-51615db505d3@gentoo.org
In Reply to: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing) by "Michał Górny"
1 Hey,
2
3 On 12/9/19 10:17 AM, Michał Górny wrote:
4 > Hello,
5 >
6 > I think the policies proposed in GLEP 81 [1] were overenthusiastic
7 > and they don't stand collision with sad Gentoo developer reality.
8 > Instead of improving the quality of resulting packages, they rather
9 > hamper their adoption and cause growing frustration.
10 >
11 > The problems I see today are:
12 >
13 >
14 > 2. Mailing list reviews don't serve their original purpose.
15 >
16 > The original purpose of mailing list reviews was to verify that
17 > the developers use new packages correctly. For example, Michael
18 > Orlitzky has found a lot of unnecessary home directories specified.
19 > Of course, that works only if people submit *ebuilds* for review.
20 >
21 > However, at some points developers arbitrarily decided to send only
22 > numbers for review. This defeats the purpose of the review in the first
23 > place.
24
25 The problem: There is still no any official documentation about using
26 acct-, and reviewing it was/is pretty much left on the shoulders of one
27 man. It's easy to say on hindsight it was implemented too quickly.
28
29
30 >
31 >
32 > 4. Assignment mechanism is not collision-prone.
33 >
34 > The secondary goal of mailing list reviews is to prevent UID/GID
35 > collisions. Sadly, it doesn't work there either. Sometimes two people
36 > request the same UID/GID, and only sometimes somebody else notices.
37 > In the end, people have hard time figuring out which number is the 'next
38 > free', sometimes they discover the number's been taken when somebody
39 > else commits it first.
40
41 If I remember correctly, at one point it was agreed not to paste ebuilds
42 because they all just looked similar, but just ask for IDs?
43
44
45 >
46 >
47 > All that considered, I'd like to open discussion how we could improve
48 > things.
49 >
50 > My proposal would be to:
51 >
52 > a. split the UID/GID range into 'high' (app) and 'low' (system)
53 > assignments, 'high' being >=100 and 'low' <100 (matching Apache suEXEC
54 > defaults),
55 >
56 > b. UIDs/GIDs in the 'high' range can be taken arbitrarily (recommending
57 > taking highest free), while in the 'low' range must be approved by QA,
58 >
59 > c. no review requirement for the 'high' range, just choose your UID/GID
60 > straight of uid-gid.txt and commit it,
61 >
62 > d. strong recommendation to use matching UID/GID for the same user/group
63 > name.
64 >
65 > WDYT?
66 >
67 >
68 > [1] https://www.gentoo.org/glep/glep-0081.html
69
70
71 I think none of the above really prevent collisions for unmotivated
72 people. They also still require manual update of uid-gid.txt, and it
73 can't be expected everyone does it. Now this is not of a big interest to
74 devs, but I believe committing non-dev acct's will get hard here,
75 because there might be some "lag" with their contributions vrt. the
76 current situation.
77
78
79 Honestly I'd say just put -1 on all acct- packages then let sys admins
80 modify them locally to whatever they need. I feel like this whole GLEP
81 just serves the minority while making many other contributors uneasy.
82
83 -- juippis

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies