1 |
On Fri, Jul 22, 2022 at 7:57 AM Joonas Niilola <juippis@g.o> wrote: |
2 |
> |
3 |
> Cross-posting to gentoo-dev and -project lists due to technical and |
4 |
> non-technical nature. Reply-to is set to -project. |
5 |
> |
6 |
> Once again new council has been elected: congratulations to the chosen |
7 |
> members! And once again many nominees expressed their wishes to see more |
8 |
> non-developer contributors to become official developers. Yet, only very |
9 |
> few people (if any) are interested in mentoring them. I get it, the |
10 |
> relationship between a mentor and their mentee is very intimate, and |
11 |
> mentoring takes a lot of time. While the Github PRs are helping us |
12 |
> increase the user contributions merged, perhaps it's distancing us from |
13 |
> creating stronger bonds with the contributors? But more about this topic |
14 |
> later. |
15 |
> |
16 |
> |
17 |
> 1st RFC: "Trusted contributor model" |
18 |
> |
19 |
> I'm proposing us to giving special commit access to our well-reputable |
20 |
> contributors (mostly proxied maintainers). They'd have access _only_ to |
21 |
> their maintained package in git-tree. To understand what I mean, check |
22 |
> git shortlog -s -n net-im/telegram-desktop-bin/ |
23 |
> git shortlog -s -n net-im/signal-desktop-bin/ |
24 |
> |
25 |
> There are few packages like these where I'd already trust the core |
26 |
> proxied maintainer to commit at their will. It's as ajak said during the |
27 |
> council election; _We_ are the bottleneck currently reviewing and |
28 |
> _testing_ contributions, and with these two examples above, 99 % of time |
29 |
> everything's in condition and we just need to merge. Obviously if these |
30 |
> trusted contributors had to touch another package, or anything in |
31 |
> profiles/ (just basically anything outside their dedicated package |
32 |
> directory) they'd have to do a PR or .patch file to be merged by |
33 |
> official developers. And they'd still need a proxy Gentoo |
34 |
> developer/project listed in metadata, at least for now, to take |
35 |
> responsibility. |
36 |
> |
37 |
> On the technical side I'm not sure how to achieve this, but I know it |
38 |
> can be done. For example the sync-repos are compiled like this all the |
39 |
> time. If this proposal gains support, I'm willing to start figuring it |
40 |
> out more in-depth. |
41 |
> |
42 |
> AFAIK Fedora and Arch have somewhat similar systems in place already. |
43 |
|
44 |
How would you suggest we track who has commit access, etc? The same |
45 |
way we do with developers, via a developer bug? |
46 |
|
47 |
I ask because I've noticed a lot of inactive proxied maintainers—one |
48 |
of which had been listed in metadata.xml for 6 years but had never |
49 |
committed to ::gentoo. |