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 |