Gentoo Archives: gentoo-dev

From: "Robin H. Johnson" <robbat2@g.o>
To: gentoo-project@l.g.o
Cc: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
Date: Fri, 22 Jul 2022 18:33:01
Message-Id: robbat2-20220722T181322-122807436Z@orbis-terrarum.net
In Reply to: [gentoo-dev] RFC: "Trusted contributor model" by Joonas Niilola
1 On Fri, Jul 22, 2022 at 02:56:33PM +0300, Joonas Niilola wrote:
2 > Cross-posting to gentoo-dev and -project lists due to technical and
3 > non-technical nature. Reply-to is set to -project.
4 ...
5 > 1st RFC: "Trusted contributor model"
6 >
7 > I'm proposing us to giving special commit access to our well-reputable
8 > contributors (mostly proxied maintainers). They'd have access _only_ to
9 > their maintained package in git-tree. To understand what I mean, check
10 > git shortlog -s -n net-im/telegram-desktop-bin/
11 > git shortlog -s -n net-im/signal-desktop-bin/
12 Conceptually, yes, I think this is a good improvement. I'd like upstream
13 to be included as well in this set, for upstreams that know their own
14 package much better than us.
15
16 > On the technical side I'm not sure how to achieve this, but I know it
17 > can be done. For example the sync-repos are compiled like this all the
18 > time. If this proposal gains support, I'm willing to start figuring it
19 > out more in-depth.
20 Technically, I've got some implementation problems.
21
22 We *can* write a simple gitolite ACL that limits scope to a directory or
23 file, e.g. CAT/PN/
24
25 BUT, we can't write a simple gitolite ACL that limits the content within
26 profiles/package.mask or other files in profiles/ (we can write hooks
27 that might be able to do this, but that still requires the challenge of
28 validation inside the file).
29
30 I'd EXPECT a contributor to WANT to package.mask a cutting edge version
31 so it has time to bake and get well-tested, but if they can't do both
32 parts of the commit themselves, this process is likely problematic.
33
34 > 2nd RFC: Recruiting proven contributors without a mentor
35 >
36 > I'm aware recruiters don't really need to ask a permission here, but I
37 > believe it's great to gauge the general feelings about this beforehand.
38 > What would you say if recruiters started more actively approaching
39 > potential developers?
40 ...
41 > But seeing the general lack of interest towards mentoring, maybe this is
42 > something we _need_ to do in near future.
43 Yes, let's make it possible to join by the quiz, and the recruiting
44 only, mentors can be optional.
45
46 But in parallel:
47
48 It's been ~7 years since I last mentored somebody, mostly for reasons of
49 time with having young kids.
50
51 How do we make the mentorship process more lightweight?
52 (and possibly the quiz process, I haven't seen how the quiz has changed
53 since I last mentored)
54
55 Let's start with a potential intersection of your two ideas:
56 (these numbers are arbitrary, but try to reflect what I see some of the
57 trusted contributors doing)
58 - 9 good submissions (patches or PRs) over a 3 month period [must be at least 3/month]
59 - will get you an invite from recruiters to join
60 - either without a mentor, or a lightweight mentor
61
62 --
63 Robin Hugh Johnson
64 Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
65 E-Mail : robbat2@g.o
66 GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
67 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Attachments

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

Replies

Subject Author
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model" Joonas Niilola <juippis@g.o>