From: Pascal Jaeger <pascal.jaeger@leimstift.de>
To: gentoo-guru@lists.gentoo.org
Subject: Re: [gentoo-guru] Discussion: lower entry barriers to the GURU
Date: Thu, 13 Oct 2022 18:24:41 +0200 [thread overview]
Message-ID: <87lepjhcss.fsf@leimstift.de> (raw)
In-Reply-To: <20221013164541.74ef9177@ventiloplattform.tastytea.de>
[-- Attachment #1: Type: text/plain, Size: 6205 bytes --]
tastytea <gentoo@tastytea.de> writes:
> On 2022-10-13 14:51+0200 Pascal Jaeger <pascal.jaeger@leimstift.de>
> wrote:
>
>> 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
>
> The positive changes appear to be:
> - no PGP key required
> - no access request required
>
> The negative changes:
> - the process of changing the tree is more convoluted for frequent
> contributors
> - special care must be taken to avoid merge conflicts
> - trusted contributors need to do more work
> - everyone needs a GitHub account
>
If we keep the current process and just make PRs possible or advertise them a bit more, I think most negative things can be ignored.
Frequent contributors can still use the way things are now. And must special care be taken regarding merge conflicts? If I add a package I most probably wont have a merge conflict. If I change a package someone else could change the package at the same time. Well, that is bad but that is also not any different to things are now. If someone pushes a commit that changes the packages I am currently working on locally and want to push, I have the same problem.
About the GitHub accounts, well… If there really is someone contributing to GURU who doesn’t have a Github-Account, so be it. That person can keep pushing to the dev branch.
So overall, I think the only real negative change would then be that it’s more work for the trusted contributors. How much more is it? I am not a trusted contributor, so I have no hands on experience what their work is, but from what I read they are reviewing commits before merging them into `master'-branch. In the other system with PRs they would review PRs before merging them into the guru?
>> 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.
>
> I believe the entry barriers to ::gentoo are way higher, because new
> packages are unlikely to be accepted and QA and style requirements are
> way stricter.
>
That is not what I meant. What I meant was authentication. As I later wrote, the QA requirements are indeed higher. The purpose of the GURU is to provide a platform for packages that do not meet ::gentoos QA standards. Otherwise we could scrap the whole idea and merge everything into ::gentoo instead.
>> 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’)
>
> Do i understand it right, that you want to shift the legal
> responsibility from the committer to the trusted contributor? That
> would make checks way more time intensive.
>
Again I am not a lawyer but I don’t see the difference here. With the current system people can push illegal stuff to the dev branch and it would be instantly published on gurus github mirror. But only when the trusted contributor merges this into the master branch it gets distributed onto user systems that have enabled the guru repo.
With a PR system people can push illegal stuff _to their own repo_ and it gets published on their repo on github. Only when the PR is merged the illegal stuff would end up in a repo from Gentoo.
I don’t know whats worse. Does this shift legal responsibility?
>> Let me know what you think of this.
>
> I agree that the initial barrier can be a bit daunting, but once the
> access request is approved, the workflow is way simpler. How about we
> drop the PGP requirement? We can reasonably assume that a person is who
> they say they are because they must have used their SSH key to push
> IMO. Or we could allow signing with the SSH key.
>
Especially because we do not require applicants to upload their GPG key together with their access request, I never understood the purpose if this anyway. I could just go around, make myself a new key an start signing commits with it. No one ever checked if that key belongs to me.
It makes sense for devs, because they upload their key to the key server, but it does not for GURU contributors.
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
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 [this message]
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=87lepjhcss.fsf@leimstift.de \
--to=pascal.jaeger@leimstift.de \
--cc=gentoo-guru@lists.gentoo.org \
/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