[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
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
Re: [gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
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
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
> 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. Actually, we are doing quite well in terms of recruiting at the moment. I would love to see this continue. And yes, mentors are important for that. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
> > 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. These who would fit here are the people where mentoring takes literally no effort. So someone could be mentor in name - which would also have the advantage that the future developer has someone to talk to if there are any problems or questions. I dont think this actually brings an improvement. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
On 22.7.2022 21.32, Robin H. Johnson wrote: > > 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. Well as I said I think the best way is to fall back to the current way of a dev merging it, 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. > > 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 > This is a bit complicated topic and I'm not sure if I'm the best one to answer the mentoring part. But I'd like to point out this kind of teaching and/or "lighweight mentoring" happen everyday in #gentoo-dev-help, #gentoo-proxy-maint and in related IRC channels, and in Github PRs... just that it's done by multiple different people in different places. So many people add a little bit to one's growth instead of one/two people adding a lot, making weaker bonds with contributors. Then again I would say the entry bar is very high right now, which in return gives us high quality developers, but maybe less people are even interested in attempting it. With these propositions I guess we can focus less on the quiz, and more on the existing positive contributions and interactions when considering someone. So to help "lightweight mentoring": Grant some person you've been proxying commit access, follow their commits and their bugzilla activity, and after some time if you get good vibes from the person, encourage them to widen their contribution areas. If they manage it after a while, they have most likely accumulated enough experience and knowledge to get recruited. If you tell people to attempt the quiz after seeing 10 commits from them, and after they've been around for a month, it's most likely going to end up being a very long road for everyone involved. Please don't try to rush and force the quiz - if GOOD verbose answers come naturally, the person is most likely ready. As I was trying to present in the original post, this way of recruiting would be for someone who's been around for a long time already (+year) and has been actively contributing and participating in the community, keeping up with Gentoo's development changes. It's not for someone trying to rush their recruitment. So in your example, I _doubt_ we'd take the initiative. But then again, it's really about people who impress us and make us say "why hasn't this person been recruited already?" - there are no metrics we should even try to list here. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
On 22.7.2022 21.18, Matt Turner wrote: > > 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. > We can see them in gitolite's configuration. For example I can already see who has guru commit access (to which branch even) or to infra-hosted personal overlays. But I don't expect this list to grow very large, at least currently. A tracker bug wouldn't hurt either, if we can enforce it as part of the process early on (it can even be visible to infra-only or something) I must admit I haven't looked into actually implementing this in the main tree but I'm pretty sure our gitolite has to be included, which itself would solve this. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
On Fri, Jul 22, 2022 at 7:57 AM Joonas Niilola 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.
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
On Fri, Jul 22, 2022 at 4:56 AM Joonas Niilola 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
