Re: [gentoo-project] RFC: "Trusted contributor model"

[John Helmert III]

On Fri, Jul 22, 2022 at 06:32:42PM +0000, Robin H. Johnson wrote:
> On Fri, Jul 22, 2022 at 02:56:33PM +0300, Joonas Niilola wrote:
> > Cross-posting to gentoo-dev and -project lists due to technical and
> > non-technical nature. Reply-to is set to -project.
> ...
> > 1st RFC: "Trusted contributor model"
> >
> > I'm proposing us to giving special commit access to our well-reputable
> > contributors (mostly proxied maintainers). They'd have access _only_ to
> > their maintained package in git-tree. To understand what I mean, check
> >   git shortlog -s -n net-im/telegram-desktop-bin/
> >   git shortlog -s -n net-im/signal-desktop-bin/
> Conceptually, yes, I think this is a good improvement. I'd like upstream
> to be included as well in this set, for upstreams that know their own
> package much better than us.
>
> > On the technical side I'm not sure how to achieve this, but I know it
> > can be done. For example the sync-repos are compiled like this all the
> > time. If this proposal gains support, I'm willing to start figuring it
> > out more in-depth.
> Technically, I've got some implementation problems.
>
> We *can* write a simple gitolite ACL that limits scope to a directory or
> file, e.g. CAT/PN/
>
> BUT, we can't write a simple gitolite ACL that limits the content within
> profiles/package.mask or other files in profiles/ (we can write hooks
> that might be able to do this, but that still requires the challenge of
> validation inside the file).

I'm not sure this kind of ACL would be necessary. These kinds of
changes are rare, and even if trusted contributors can't make them,
the load would still be significantly decreased for the developers
that proxy commits.

> I'd EXPECT a contributor to WANT to package.mask a cutting edge version
> so it has time to bake and get well-tested, but if they can't do both
> parts of the commit themselves, this process is likely problematic.
>
> > 2nd RFC: Recruiting proven contributors without a mentor
> >
> > I'm aware recruiters don't really need to ask a permission here, but I
> > believe it's great to gauge the general feelings about this beforehand.
> > What would you say if recruiters started more actively approaching
> > potential developers?
> ...
> > But seeing the general lack of interest towards mentoring, maybe this is
> > something we _need_ to do in near future.
> Yes, let's make it possible to join by the quiz, and the recruiting
> only, mentors can be optional.
>
> But in parallel:
>
> It's been ~7 years since I last mentored somebody, mostly for reasons of
> time with having young kids.
>
> How do we make the mentorship process more lightweight?
> (and possibly the quiz process, I haven't seen how the quiz has changed
> since I last mentored)
>
> Let's start with a potential intersection of your two ideas:
> (these numbers are arbitrary, but try to reflect what I see some of the
> trusted contributors doing)
> - 9 good submissions (patches or PRs) over a 3 month period [must be at least 3/month]
> - will get you an invite from recruiters to join
> - either without a mentor, or a lightweight mentor
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
> E-Mail   : robbat2@g.o
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136