|
|
Subscribe / Log in / New account

Pulling GitHub into the kernel process

Pulling GitHub into the kernel process

Posted Jun 24, 2021 0:07 UTC (Thu) by q_q_p_p (guest, #131113)
Parent article: Pulling GitHub into the kernel process

As long as GitHub doesn't support PRs from git repositories not hosted on GitHub servers and requires an account to even send a PR or small patch, fuck GitHub. This vendor lock-in and Ojeda approach ("Ojeda wants to move the main place for patch review and the like from the mailing lists to GitHub.") shouldn't be acceptable for kernel development.

Any solution to kernel-development problems, should be at least as decentralized as email and git are. I don't mind being subscribed to the kernel mailing lists with email address hosted on my server (still subscription is not necessary to contribute to the kernel), I do mind if I'm forced to have an account on microsoft-owned platform to contribute even the smallest patch.


to post comments

Pulling GitHub into the kernel process

Posted Jun 24, 2021 6:45 UTC (Thu) by zoobab (guest, #9945) [Link] (2 responses)

Github is not open source.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 7:26 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Neither was Bitkeeper. With luck the lessons from there will still be strong enough to avoid any vendor lockin in terms of the primary approaches to contributing to the kernel, but there are already people who use proprietary software to contribute to Linux and there are already people who use Github who would like to contribute to Linux, and I think there's a meaningful benefit in enabling that.

Pulling GitHub into the kernel process

Posted Jun 26, 2021 6:52 UTC (Sat) by cpitrat (subscriber, #116459) [Link]

My first interrogation reading this was why GitHub rather than GitLab? I guess the idea is to touch the large audience, not just to offer a nicer workflow ...

Pulling GitHub into the kernel process

Posted Jun 24, 2021 8:20 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (6 responses)

Yes they'd be putting themselves in the hands of a single corporation, the same way it was before git. That would not be wise, but I don't think it will be allowed any time soon.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 10:46 UTC (Thu) by ojeda (subscriber, #143370) [Link] (5 responses)

We are not putting ourselves in the hands of a single corporation.

GitHub offers a service which is useful to us. If tomorrow GitHub stops being useful or a new, better service appears, we will migrate. Migrating is easy enough.

And, to be clear, the usual ML-based workflow still works and GitHub is not stopping us from using it.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 14:58 UTC (Thu) by oever (guest, #987) [Link] (4 responses)

Migration is not easy. All issues and pull requests are tied to GitHub user accounts. All 'stars' are tied to GitHub user accounts. These cannot be moved.

GitHub has a lock-in by login.

Using email for development removes the information intermediary.

Any web based front-end that uses cryptographically signed issues, PRs, 'stars' and other contributions where the private keys are not part of the website would be fine.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 15:43 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

Stars are pretty meaningless to workflows, so that doesn't seem all that important. Yes, issues and PRs being attributed to user accounts makes it harder to find out who to contact about it once moving, but that's the case if someone changes their email address (say, employment change, de-Googlification, or whatever).

In any case, the important bits are still retrievable just as easily in an email workflow. Using that information can be easier or harder depending on circumstances, but there's no guarantee that any of that works in an arbitrary future anyways.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 20:52 UTC (Thu) by marcH (subscriber, #57642) [Link] (2 responses)

> In any case, the important bits are still retrievable just as easily in an email workflow.

Depends whether you consider the code review important or not.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 21:08 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

I'm not sure what you mean. What is not retrievable via the API about a GitHub (or GitLab) review that you're referring to?

Pulling GitHub into the kernel process

Posted Jun 26, 2021 12:54 UTC (Sat) by andyc (subscriber, #1130) [Link]

I interpreted his comment as "code review over email doesn't work", projects like the very one we're discussing! puts that idea to rest.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 10:32 UTC (Thu) by ojeda (subscriber, #143370) [Link]

> This vendor lock-in and Ojeda approach ("Ojeda wants to move the main place for patch review and the like from the mailing lists to GitHub.") shouldn't be acceptable for kernel development.

To be clear: there is no requirement to have a GitHub account -- you can still send us patches through the mailing list and we can still review them there.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds