[gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

[Michał Górny]

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 >=100 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

-- 
Best regards,
Michał Górny