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

    From Alec Warner@21:1/5 to juippis@gentoo.org on Fri Jul 22 17:20:01 2022
    On Fri, Jul 22, 2022 at 4:56 AM Joonas Niilola <juippis@gentoo.org> wrote:

    Cross-posting to gentoo-dev and -project lists due to technical and non-technical nature. Reply-to is set to -project.

    Once again new council has been elected: congratulations to the chosen members! And once again many nominees expressed their wishes to see more non-developer contributors to become official developers. Yet, only very
    few people (if any) are interested in mentoring them. I get it, the relationship between a mentor and their mentee is very intimate, and mentoring takes a lot of time. While the Github PRs are helping us
    increase the user contributions merged, perhaps it's distancing us from creating stronger bonds with the contributors? But more about this topic later.


    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/

    There are few packages like these where I'd already trust the core
    proxied maintainer to commit at their will. It's as ajak said during the council election; _We_ are the bottleneck currently reviewing and
    _testing_ contributions, and with these two examples above, 99 % of time everything's in condition and we just need to merge. Obviously if these trusted contributors had to touch another package, or anything in
    profiles/ (just basically anything outside their dedicated package
    directory) they'd have to do a PR or .patch file to be merged by
    official developers. And they'd still need a proxy Gentoo
    developer/project listed in metadata, at least for now, to take responsibility.

    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.

    Who decides which contributor gets access to which package?
    Is there a flow to eventually onboard contributors as developers?
    Why are the contributors not developers themselves, just with scoped
    ::gentoo access?

    -A


    AFAIK Fedora and Arch have somewhat similar systems in place already.


    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? And currently I'm talking about people who have
    been active for a very long time (+year or two), who keep up with development-wise changes in Gentoo (eclasses, EAPI, virtuals...),
    participate in the community, and always provide top-quality
    contributions, but for some reason never got a mentor? I'd like to point
    out that this method would only be for the very few ones and recruiting through mentoring would still be the desired method. Recruiting through recruiters would still require the candidate to fill the
    ebuild/developer quiz, and they'd have to pass it without a mentor. So
    I'll emphasize: Currently only few special ones would qualify.

    But seeing the general lack of interest towards mentoring, maybe this is something we _need_ to do in near future.

    -- juippis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matt Turner@21:1/5 to juippis@gentoo.org on Fri Jul 22 20:20:02 2022
    On Fri, Jul 22, 2022 at 7:57 AM Joonas Niilola <juippis@gentoo.org> wrote:

    Cross-posting to gentoo-dev and -project lists due to technical and non-technical nature. Reply-to is set to -project.

    Once again new council has been elected: congratulations to the chosen members! And once again many nominees expressed their wishes to see more non-developer contributors to become official developers. Yet, only very
    few people (if any) are interested in mentoring them. I get it, the relationship between a mentor and their mentee is very intimate, and mentoring takes a lot of time. While the Github PRs are helping us
    increase the user contributions merged, perhaps it's distancing us from creating stronger bonds with the contributors? But more about this topic later.


    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/

    There are few packages like these where I'd already trust the core
    proxied maintainer to commit at their will. It's as ajak said during the council election; _We_ are the bottleneck currently reviewing and
    _testing_ contributions, and with these two examples above, 99 % of time everything's in condition and we just need to merge. Obviously if these trusted contributors had to touch another package, or anything in
    profiles/ (just basically anything outside their dedicated package
    directory) they'd have to do a PR or .patch file to be merged by
    official developers. And they'd still need a proxy Gentoo
    developer/project listed in metadata, at least for now, to take responsibility.

    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.

    AFAIK Fedora and Arch have somewhat similar systems in place already.

    How would you suggest we track who has commit access, etc? The same
    way we do with developers, via a developer bug?

    I ask because I've noticed a lot of inactive proxied maintainers—one
    of which had been listed in metadata.xml for 6 years but had never
    committed to ::gentoo.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin H. Johnson@21:1/5 to Joonas Niilola on Fri Jul 22 20:40:01 2022
    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'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@gentoo.org
    GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
    GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2
    Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it.

    iQKTBAABCgB9FiEEveu2pS8Vb98xaNkRGTlfI8WIJsQFAmLa7UhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJE RUJCNkE1MkYxNTZGREYzMTY4RDkxMTE5Mzk1RjIzQzU4ODI2QzQACgkQGTlfI8WI JsTYlg/+PuspBGqEDt2gYYQFo9UgIzYtpAxgqZZN5B8sEieTV9NLKnOvfO80fvo9 XKgSylgyFaE6fx+rL1g21Q+jE/AbWseQnOcsFcPyoEAVlApNQvwrvbN1wYXddArw vpeY5aNnxqDjM1+zCAp0/0p5XahoSe4RNWyw4u8CIYbu3N103Hs8lJBEY46wlXol Y59mju+QNcu/Z+lzYr9whABEMcGh7h68wZuYQ8fTemPV2Dr9qpv/cq5JLwtQw3mY DLccgboIR49sLYzKP5zqv4rnGRl/tOUC5+5pXhkRazSVofbkaHu4sBBY9rQ72vJ0 avkoXFpQvf/eUD3zDv2fuRFoF0X4puxly1fcYiHv6Ss48vBSNl30uLH9/bokD3Kw NgClYc9Ezor6s5A3vGDh
  • From Zoltan Puskas@21:1/5 to All on Tue Jul 26 22:40:01 2022
    Hey,


    How would you suggest we track who has commit access, etc? The same
    way we do with developers, via a developer bug?

    I believe proxy maintainers already have a bug assigned to them (at
    least I have one), so maybe just a comment or a special tag would be
    suffient on these bugs to signify commit access.

    I ask because I've noticed a lot of inactive proxied maintainers—one
    of which had been listed in metadata.xml for 6 years but had never
    committed to ::gentoo.


    Should these packages not be dropped to maintainer needed? Just like
    regular developers, wouldn't it be reasonable to expect a minimal level of activiy from proxied maintainers (even if not as strict) or otherwise be dropped from a package?

    Zoltan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Dummer@21:1/5 to All on Wed Jul 27 01:40:01 2022
    Am 22.07.22 um 21:10 schrieb Joonas Niilola:
    ..., via Github PR or other means. I'd say pushing these
    experimental packages is rather rare (for proxied people at least), and
    can also be added without KEYWORDS for example.

    I agree here. And I think the proxy maintainers can open PRs like now
    which can be merged by a bot (after the QA bot has completed
    successfully). This bot can have a ACL of person + package which is
    maintained separately.

    For special cases like changes to package.mask the regular PR flow can
    be used.

    My proposal here: better some automation for 90% purpose than a long
    discussion with many proposals and finally no automation - because none
    of the proposals has  100% satisfaction.

    Martin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)