Re: Migrate away from vger to GitHub or (on-premise) GitLab?

From: Hans Meiser <brille1@hotmail.com>
Date: Feb 6, 2024, 07:22 UTC
Message-ID: <DB9P195MB213080E6DD9ECA0EE3D2B491E2462@DB9P195MB2130.EURP195.PROD.OUTLOOK.COM>
In-Reply-To: <20240202212809.GA36616@mit.edu>

> Please, keep in mind that not everyone lives in a web browser and
> loves to click around.  Some people simply prefer to use the CLI
> utilities and to press the keys on their keyboards, and are very
> efficient while doing that.

You are aware of the fact that all these Git collaboration websites are providing a REST interface? So, you are free to access any function by means of CLI?

Show 20 quoted lines

> As a Linux kernel subsystem maintainer, I am super grateful for those
> who do code reviews and those who work test regressions, because in
> general, that which doesn't get done by other developers ends up
> getting done by the maintainers and project leads if it's going to
> happen at all.
> 
> When it comes to requests like "you should migrate the project to use
> some forge web site, because we can't be bothered to use e-mail, and
> web interfaces are the new hotness", the entitlement that comes from
> that request (which is in the subject line of this thread), can
> sometimes be a bit frustrating.
> 
> Going back to the original topic of this thread, my personal
> experience has been that the *vest* percentage of pull requests that I
> get from github tend to be drive-by pull requests that are very low
> quality, especially compared to those that I get via the mailing list.
> So making a change to use a forge which might result in a larger
> number of lower quality code contributions, when code review bandwidth
> might be more of a bottlenck, might not be as appealing as some might
> think.

Again, you are aware of the fact that Git collaboration websites provide a powerful user rights management? (https://docs.gitlab.com/ee/user/permissions.html https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization)

Using Git collaboration websites you can easily control and filter who will be contributing. And you are able to focus on issues and filter out spammers. It's quite the contrary of of what you have now with your mailing list. A vanilla student from the "axis of evil" could bomb your mailing list in a snap by just registering a dozen new e-mail accounts and writing a script that bloated your mailing list. And you cannot thwart that at all.

With your mailing list approach you don't have ANY sort of gateway to keep away spam or "low quality" contributions other by means of the intrinsic clumsiness and intricateness of a mailing list. After having subscribed to your mailing list, my e-mail spam rate immediately increased significantly.

Again, on Git collaboration websites you can hide your personal access information and focus on your repository tasks rather than wasting your time on cumbersome additional and unneccessary work.

I'm getting the impression that you didn't yet seriously investigate on the features these Git collaboration websites provide.

Let me finish this thread from my side now. I suggested a way to improve your daily business by employing tools that have been established and proven to raise code and documentation quality and that will allow you to focus on important tasks rather than wasting time on an old fashioned workflow. Well, it's up to you now to decide whether to stick here or to migrate.

Cheers, Axel