Gentoo Archives: gentoo-dev

From: Joonas Niilola <juippis@g.o>
To: gentoo-dev@l.g.o, gentoo-project@l.g.o
Subject: [gentoo-dev] RFC: "Trusted contributor model"
Date: Fri, 22 Jul 2022 11:57:10
1 Cross-posting to gentoo-dev and -project lists due to technical and
2 non-technical nature. Reply-to is set to -project.
4 Once again new council has been elected: congratulations to the chosen
5 members! And once again many nominees expressed their wishes to see more
6 non-developer contributors to become official developers. Yet, only very
7 few people (if any) are interested in mentoring them. I get it, the
8 relationship between a mentor and their mentee is very intimate, and
9 mentoring takes a lot of time. While the Github PRs are helping us
10 increase the user contributions merged, perhaps it's distancing us from
11 creating stronger bonds with the contributors? But more about this topic
12 later.
15 1st RFC: "Trusted contributor model"
17 I'm proposing us to giving special commit access to our well-reputable
18 contributors (mostly proxied maintainers). They'd have access _only_ to
19 their maintained package in git-tree. To understand what I mean, check
20 git shortlog -s -n net-im/telegram-desktop-bin/
21 git shortlog -s -n net-im/signal-desktop-bin/
23 There are few packages like these where I'd already trust the core
24 proxied maintainer to commit at their will. It's as ajak said during the
25 council election; _We_ are the bottleneck currently reviewing and
26 _testing_ contributions, and with these two examples above, 99 % of time
27 everything's in condition and we just need to merge. Obviously if these
28 trusted contributors had to touch another package, or anything in
29 profiles/ (just basically anything outside their dedicated package
30 directory) they'd have to do a PR or .patch file to be merged by
31 official developers. And they'd still need a proxy Gentoo
32 developer/project listed in metadata, at least for now, to take
33 responsibility.
35 On the technical side I'm not sure how to achieve this, but I know it
36 can be done. For example the sync-repos are compiled like this all the
37 time. If this proposal gains support, I'm willing to start figuring it
38 out more in-depth.
40 AFAIK Fedora and Arch have somewhat similar systems in place already.
43 2nd RFC: Recruiting proven contributors without a mentor
45 I'm aware recruiters don't really need to ask a permission here, but I
46 believe it's great to gauge the general feelings about this beforehand.
47 What would you say if recruiters started more actively approaching
48 potential developers? And currently I'm talking about people who have
49 been active for a very long time (+year or two), who keep up with
50 development-wise changes in Gentoo (eclasses, EAPI, virtuals...),
51 participate in the community, and always provide top-quality
52 contributions, but for some reason never got a mentor? I'd like to point
53 out that this method would only be for the very few ones and recruiting
54 through mentoring would still be the desired method. Recruiting through
55 recruiters would still require the candidate to fill the
56 ebuild/developer quiz, and they'd have to pass it without a mentor. So
57 I'll emphasize: Currently only few special ones would qualify.
59 But seeing the general lack of interest towards mentoring, maybe this is
60 something we _need_ to do in near future.
62 -- juippis


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