Gentoo Archives: gentoo-dev

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

Attachments

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

Replies