From: John Helmert III <ajak@gentoo.org>
To: Pascal Jaeger <pascal.jaeger@leimstift.de>
Cc: gentoo-guru@lists.gentoo.org
Subject: Re: [gentoo-guru] Discussion: lower entry barriers to the GURU
Date: Thu, 13 Oct 2022 09:18:12 -0500 [thread overview]
Message-ID: <Y0geJLj1dlRx8XUH@gentoo.org> (raw)
In-Reply-To: <87o7ufhlon.fsf@leimstift.de>
[-- Attachment #1: Type: text/plain, Size: 4789 bytes --]
On Thu, Oct 13, 2022 at 02:51:41PM +0200, Pascal Jaeger wrote:
> Hi fellow Guru Mailing list users,
>
> I wanted to start a small discussion regarding the entry barriers for new Guru contributors. To wrap up the current situation, in order to get write access to the GURU, people need to:
> • generate a ssh key
> • generate a gpg key
> • file a bug requesting access at b.g.o with their real name, ssh key and the statement they want stick to the project guidelines
> • wait for the bug to be approved and their ssh key to be added
>
> Now, Gentoo has a thriving community that makes ebuilds. There are overlays all over the place, so it is clearly not the problem that we don’t have people making ebuilds. But the community is scattered into many many different overlays, that often contain ebuilds for the same packages. Somehow Arch Linux (clearly their AUR was the model for the GURU) is able to bundle most of that into one single repo and I think this is because their entry barriers are lower. Iirc they just need to upload their SSH key and they can start commiting. [1] (Although I could me wrong here, I never contributed to the AUR and only read about it.)
> Also I heard it several online discussions that people know how to create an ebuild for their package but they don’t know how to get it into the GURU or they don’t want to because of the effort.
>
> Obviously the AURs way it is not really a viable option for us. For the the GURU because we need peoples mail addresses for bug reports and I think we can also agrees that we don’t want the GURU to be of the same questionable legal status as the AUR, they have packages with copyright problems everywhere and noone seems to care about it.
> But instead we could utilize an even easier process we already know and use in Gentoo: The one of proxy maintainers. So instead of giving people direct write access onto the `dev'-Branch of the gurus repo, we could allow people to make pull requests on the GURUs Github mirror like we do with PRs on ::gentoos Github mirror.
> Although I assume most people are already familiar, to sum up this process, so we all know what we are talking about:
> • Contributor needs a Github account
> • Contributor forkes the Gurus Github mirror, this means the contributor gets a copy of that repository as his own with write access
> • Contributor makes changes in his repository (that is adding packages, dropping old version etc.)
> • Contributor opens a pull request on GitHub to merge his commited changes into the offical guru repository
> • Trusted Contributor reviews the pull request, suggests changes and merges it inte the official guru repo when ready
Making a pull request is significantly higher overhead *each time*
commits are made that someone wants to merge. Requesting commit access
directly is a one-time thing.
Why would trusted contributors need to review the PRs? Regular
contributors have dev access so they could merge PRs if they want.
> The review of the PR by the trusted contributors would take place in the PR like it does with proxy maintainers PRs as well. Personally I do not see why the entry barriers for contributing to GURU should be higher than the entry barriers to contribute to ::gentoo. The difference to ::gentoo should be, that the QA check for the GURU should be less strict. (Or not present at all, as it is now. Because trusted contributors should not hold up merges because of QA issues and only tell contributors about them so they can learn.) [2]
> Because the processes of the guru would then be closer of the processes of the ::gentoo repo and proxy maintainers, this would also help recruiting new proxy maintainers and probably new developers to Gentoo I think.
>
> The process that is now in place is also to get peoples email addresses to send them bug reports for their packages, but we could require them to put their email address into the manifest.xml for every package they contribute.
> Also I think the statement to stick to the guidelines is not really needed anymore then (but I am not a lawyer). When people have illegal stuff in their PR, they only uploaded it to their own repository until it is merged. It would be the task of the trusted contributors to detect such things and refuse to merge the PR. (As it is now with moving commits from `dev' branch to `master')
I'm not really sure what change you're suggesting in any case. PRs
aren't turned off for https://github.com/gentoo/guru, so people can
already use that if they want?
> Let me know what you think of this.
>
> [1] <https://wiki.archlinux.org/title/AUR_submission_guidelines#Authentication>
> [2] <https://wiki.gentoo.org/wiki/Project:GURU/Information_for_Trusted_Contributors>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-11-24 22:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-13 12:51 [gentoo-guru] Discussion: lower entry barriers to the GURU Pascal Jaeger
2022-10-13 14:18 ` John Helmert III [this message]
2022-10-13 14:18 ` Andrew Ammerlaan
2022-10-13 14:33 ` Pascal Jaeger
2022-10-13 14:53 ` tastytea
2022-10-13 15:01 ` Andrew Ammerlaan
2022-10-13 14:45 ` tastytea
2022-10-13 16:24 ` Pascal Jaeger
2022-10-13 19:26 ` tastytea
2022-10-13 21:09 ` Pascal Jaeger
2022-10-13 15:25 ` Michał Górny
2022-10-13 17:12 ` Pascal Jaeger
2022-10-13 17:29 ` Nicola Smaniotto
2022-10-13 17:39 ` Pascal Jaeger
2022-10-14 8:30 ` Anna “CyberTailor”
2022-10-17 1:49 ` NRK
2022-10-17 7:00 ` Pascal Jaeger
2022-10-17 7:39 ` Andrew Ammerlaan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0geJLj1dlRx8XUH@gentoo.org \
--to=ajak@gentoo.org \
--cc=gentoo-guru@lists.gentoo.org \
--cc=pascal.jaeger@leimstift.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox