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 |