5 ms·

Pulling GitHub into the Linux kernel process

43 points by chmaynard 5y ago

seneca 5y ago
I, for one, would be quite sad to see Linux on Github. An open source alternative, and preferably one without the political baggage and MS-backing of Github, would be a better fit.
- OJFord 5y ago
  Sadness trigger warning, brace yourself: https://github.com/torvalds/linux https://github.com/torvalds/linux
  - jacobr1 5y ago
    ... and look at all the PRs that are not being merged. He should disable them.
    - duskwuff 5y ago
      Unfortunately, there's no way to disable pull requests on Github. The closest you can get is an Action to automatically close them when they're created.
    - OJFord 5y ago
      I didn't claim they were, just pointing out it's 'on GitHub' as much as it will be already.
  - edgyquant 5y ago
    I think that user means for it to use GitHub as its main repo (which isn’t happening.) What you’ve linked is a mirror.
    - OJFord 5y ago
      I know it's a mirror. As you say still will be, just more mirrored back. Just pointing out it's already 'on GitHub' as much as it will be.
- vlovich123 5y ago
  All this tool is doing is making Github a fancy web frontend for sending a patch to the LKML. From that perspective, all this does is make it more convenient for those with a GitHub account to not have to learn a totally new workflow. I would think this would be easily portable to any other service (e.g. create a similar bot for Gitlab, Bitbucket, etc). There's a separate discussion about whether the workflow more broadly should move out of the LKML. This might look like having patch sets posted to the LKML automatically ingested into Gerrit. All of this seems pretty sane to modernize the workflow & make it a more familiar one for those working on the Linux kernel professionally. E-mailing patch sets around is decidedly a very old way to do code review that's not generally found in modern professional shops (cries of "this is for the worse" notwithstanding because that feels like a VIM vs emacs complaint).
- judge2020 5y ago
  It’s not transitioning entirely to GitHub, but is “ a bot that can turn a GitHub pull request (PR) into a well-formed patch series to send to the proper reviewers and mailing lists”. Also, Linux is already mirrored to GH https://GitHub.com/torvalds/Linux https://GitHub.com/torvalds/Linux
  - deleted 5y ago
    [deleted]
  - jeroenhd 5y ago
    Not the parent, but I'd still much rather see such a bot for Gitlab or Gitea which are (mostly) open source and provide similar developer conveniences. I suppose they made this change because Microsoft still hosts the Linux kernel for free on their platform and that's probably the main mirror people clone it from. Still, making proprietary patchwork for such an opinionated open source project seems a little silly to me.
    - yjftsjthsd-h 5y ago
      Ideally, wouldn't we want a bot for every such platform? One for github... but also for gitlab, and gitea, and bitbucket, and sourcehut, etc.
    - silly-silly 5y ago
      > that's probably the main mirror people clone it from. I very much doubt this is true.
flerchin 5y ago
It is insane to me that kernel maintainers do not have build pipelines that automatically run for every PR. The computers should be checking formatting, basic compilation, testing, etc etc.
- Ericson2314 5y ago
  At the very least, before I opened the floodgates to github-style contributions, I would want to already have damn good CI in place. While I firmly believe in "trickle up" economics", I still believe in trickle down productivity investment. It is important to increase the productivity of patch review (CI, etc., done by the experts manually today) before increasing the productivity of patch submission (done by everyone else).
- MuffinFlavored 5y ago
  I'd love to hear from Linus why they don't have that. I know it's probably super hard to "unit test" some of this stuff but... does the Linux kernel have effectively 0 testing?
  - viraptor 5y ago
    No, they have various testing platforms and harnesses, but they're very component oriented. For example people doing filesystem development will use https://github.com/kdave/xfstests https://github.com/kdave/xfstests for validation. Others will use different tools. At Linux kernel level you can't effectively have "a CI". Unless you have massive amounts of funds and time to invest of course. I'm sure MS has some complex pre-release automation.
- ploxiln 5y ago
  They actually do, it's just somewhat distributed. https://01.org/lkp/documentation/0-day-test-service https://01.org/lkp/documentation/0-day-test-service https://linux.kernelci.org/job/ https://linux.kernelci.org/job/ "kernel test robot" example email: https://lore.kernel.org/netdev/202102070253.xooT3PWR-lkp@intel.com/ https://lore.kernel.org/netdev/202102070253.xooT3PWR-lkp@int...
- 5y ago
neolog 5y ago
Is this what Radicle is designed for? > Radicle is a decentralized code collaboration network built on open protocols . It enables developers to collaborate on code without relying on trusted intermediaries. Radicle was designed to provide similar functionality to centralized code collaboration platforms — or "forges" — while retaining Git’s peer-to-peer nature, building on what made distributed version control so powerful in the first place. https://docs.radicle.xyz/docs/what-is-radicle.html https://docs.radicle.xyz/docs/what-is-radicle.html
- duskwuff 5y ago
  No, that looks like some kind of cryptocurrency nonsense. It's not clear that they even have a working product, let alone one which would be appropriate for the Linux kernel. (The discussion of a "decentralized" development model seems particularly strange, and completely at odds with how kernel development works.)
  - viraptor 5y ago
    Hold your crypto bashing for a moment. Basic Radicle features do not rely on the blockchain at all. The ethereum extras are only for things like for name reservation and organisation management. (And for project development funding) The product itself exists and is usable in a very basic form for a while now. (You can download it from https://radicle.xyz https://radicle.xyz) It's not complete though and definitely not ready for the kernel's use case at the moment.
- viraptor 5y ago
  Kind of - it's closer to the mailing list workflow than GitHub. However the automation integration is not in place yet in any form, which this article is mostly about. Maybe in a couple of years.
muricula 5y ago
The Linux Kernel development process is old-fashioned and there are lot of particular processes and conventions which make submitting a patch difficult. Also, if you use gmail with mutt to submit a patch, you have to change your email preferences to make gmail less secure[1]. It would be nice to have a friendlier way to contribute to the kernel, and a GitHub bridge seems like a good idea. [1]: https://medium.com/@crhenr/submitting-your-first-patch-to-the-linux-kernel-e81d2541fac6 https://medium.com/@crhenr/submitting-your-first-patch-to-th...
- andrewchambers 5y ago
  This is google imposed FUD to exercise control over users. They didn't need to design like that, but they want to make it hard to use things that are not google controlled.
  - judge2020 5y ago
    IMAP/SMTP access with only your password is extremely insecure. Especially as most non-techie humans don’t use a password manager or even a strong password.
    - andrewchambers 5y ago
      Yes, but google could easily support per application passwords. They just don't want to... in fact, they used to and removed it. They could also invest in other ways to make existing workflows work securely instead of imposing their own ones.
      - judge2020 5y ago
        Sounds like oauth, which is an open standard.
        jeroenhd 5y ago
        OAuth is far from standard in email. Google is the only company I know of that uses it for email. Per-application passwords are static passwords you generate for special applications. This way, the standard IMAP/SMTP logins will work, but a leaked password does not expose your entire Google account, only the email part. It also allows revocation of one application without re-entering your password on every device. It works flawlessly for many services, and Google supports/supported it as well. Using it just flags/flagged your account as "insecure" for some reason. Probably because they want you to use their propietary OAuth flow where they have more control over your software.
SkyMarshal 5y ago
All this research and not a single mention of Source Hut? Source Hut is designed to be a web-based interface to Git, but which uses Git's built-in email-based patch workflow instead of some proprietary interface like Github. It seems close to what they're looking for, and relatively easily hackable if missing anything they need. https://sourcehut.org/ https://sourcehut.org/ Good writeup on project philosophy: https://drewdevault.com/2018/11/15/sr.ht-general-availability.html https://drewdevault.com/2018/11/15/sr.ht-general-availabilit...
- goodpoint 5y ago
  Indeed, SourceHut would be an excellent choice for the kernel workflow.
  - stavros 5y ago
    Wait, why do I keep pronouncing it "Sir Hat"?
    - SkyMarshal 5y ago
      Drew originally called it Sir Hat, before changing it to Source Hut: https://drewdevault.com/2018/11/15/sr.ht-general-availability.html https://drewdevault.com/2018/11/15/sr.ht-general-availabilit... https://news.ycombinator.com/item?id=18930554 https://news.ycombinator.com/item?id=18930554 https://news.ycombinator.com/item?id=19100986 https://news.ycombinator.com/item?id=19100986
      - stavros 5y ago
        Ahh, thanks, so I didn't make it up!
        deleted 5y ago
        [deleted]
        deleted 5y ago
        [deleted]
beprogrammed 5y ago
Looking at the sheer number of garbage/troll pull requests to Torvalds repo on GitHub makes me understand the resistance to this. You could imagine the constant flow of drive-by spam PR's you would be getting.
thatsabadidea 5y ago
Embrace, Extend, Extinguish No thanks.
geenat 5y ago
Bad idea. Distributed development ensures the kernel is difficult to corrupt or destroy. git was designed for this purpose. If a dev cannot be bothered to learn the distributed process, they should not be submitting code to the kernel. No corporation such as github, can be trusted with so much power. +1 respect to Linus as usual.
- arp242 5y ago
  No one is talking about moving Linux to GitHub.

43 points by chmaynard 5y ago

I, for one, would be quite sad to see Linux on Github. An open source alternative, and preferably one without the political baggage and MS-backing of Github, would be a better fit.

OJFord 5y ago
Sadness trigger warning, brace yourself: https://github.com/torvalds/linux https://github.com/torvalds/linux
- jacobr1 5y ago
  ... and look at all the PRs that are not being merged. He should disable them.
  - duskwuff 5y ago
    Unfortunately, there's no way to disable pull requests on Github. The closest you can get is an Action to automatically close them when they're created.
  - OJFord 5y ago
    I didn't claim they were, just pointing out it's 'on GitHub' as much as it will be already.
- edgyquant 5y ago
  I think that user means for it to use GitHub as its main repo (which isn’t happening.) What you’ve linked is a mirror.
  - OJFord 5y ago
    I know it's a mirror. As you say still will be, just more mirrored back. Just pointing out it's already 'on GitHub' as much as it will be.
vlovich123 5y ago
All this tool is doing is making Github a fancy web frontend for sending a patch to the LKML. From that perspective, all this does is make it more convenient for those with a GitHub account to not have to learn a totally new workflow. I would think this would be easily portable to any other service (e.g. create a similar bot for Gitlab, Bitbucket, etc). There's a separate discussion about whether the workflow more broadly should move out of the LKML. This might look like having patch sets posted to the LKML automatically ingested into Gerrit. All of this seems pretty sane to modernize the workflow & make it a more familiar one for those working on the Linux kernel professionally. E-mailing patch sets around is decidedly a very old way to do code review that's not generally found in modern professional shops (cries of "this is for the worse" notwithstanding because that feels like a VIM vs emacs complaint).
judge2020 5y ago
It’s not transitioning entirely to GitHub, but is “ a bot that can turn a GitHub pull request (PR) into a well-formed patch series to send to the proper reviewers and mailing lists”. Also, Linux is already mirrored to GH https://GitHub.com/torvalds/Linux https://GitHub.com/torvalds/Linux
- deleted 5y ago
  [deleted]
- jeroenhd 5y ago
  Not the parent, but I'd still much rather see such a bot for Gitlab or Gitea which are (mostly) open source and provide similar developer conveniences. I suppose they made this change because Microsoft still hosts the Linux kernel for free on their platform and that's probably the main mirror people clone it from. Still, making proprietary patchwork for such an opinionated open source project seems a little silly to me.
  - yjftsjthsd-h 5y ago
    Ideally, wouldn't we want a bot for every such platform? One for github... but also for gitlab, and gitea, and bitbucket, and sourcehut, etc.
  - silly-silly 5y ago
    > that's probably the main mirror people clone it from. I very much doubt this is true.

flerchin 5y ago

It is insane to me that kernel maintainers do not have build pipelines that automatically run for every PR. The computers should be checking formatting, basic compilation, testing, etc etc.

Ericson2314 5y ago
At the very least, before I opened the floodgates to github-style contributions, I would want to already have damn good CI in place. While I firmly believe in "trickle up" economics", I still believe in trickle down productivity investment. It is important to increase the productivity of patch review (CI, etc., done by the experts manually today) before increasing the productivity of patch submission (done by everyone else).
MuffinFlavored 5y ago
I'd love to hear from Linus why they don't have that. I know it's probably super hard to "unit test" some of this stuff but... does the Linux kernel have effectively 0 testing?
- viraptor 5y ago
  No, they have various testing platforms and harnesses, but they're very component oriented. For example people doing filesystem development will use https://github.com/kdave/xfstests https://github.com/kdave/xfstests for validation. Others will use different tools. At Linux kernel level you can't effectively have "a CI". Unless you have massive amounts of funds and time to invest of course. I'm sure MS has some complex pre-release automation.
ploxiln 5y ago
They actually do, it's just somewhat distributed. https://01.org/lkp/documentation/0-day-test-service https://01.org/lkp/documentation/0-day-test-service https://linux.kernelci.org/job/ https://linux.kernelci.org/job/ "kernel test robot" example email: https://lore.kernel.org/netdev/202102070253.xooT3PWR-lkp@intel.com/ https://lore.kernel.org/netdev/202102070253.xooT3PWR-lkp@int...
5y ago

neolog 5y ago

Is this what Radicle is designed for? > Radicle is a decentralized code collaboration network built on open protocols . It enables developers to collaborate on code without relying on trusted intermediaries. Radicle was designed to provide similar functionality to centralized code collaboration platforms — or "forges" — while retaining Git’s peer-to-peer nature, building on what made distributed version control so powerful in the first place. https://docs.radicle.xyz/docs/what-is-radicle.html https://docs.radicle.xyz/docs/what-is-radicle.html

duskwuff 5y ago
No, that looks like some kind of cryptocurrency nonsense. It's not clear that they even have a working product, let alone one which would be appropriate for the Linux kernel. (The discussion of a "decentralized" development model seems particularly strange, and completely at odds with how kernel development works.)
- viraptor 5y ago
  Hold your crypto bashing for a moment. Basic Radicle features do not rely on the blockchain at all. The ethereum extras are only for things like for name reservation and organisation management. (And for project development funding) The product itself exists and is usable in a very basic form for a while now. (You can download it from https://radicle.xyz https://radicle.xyz) It's not complete though and definitely not ready for the kernel's use case at the moment.
viraptor 5y ago
Kind of - it's closer to the mailing list workflow than GitHub. However the automation integration is not in place yet in any form, which this article is mostly about. Maybe in a couple of years.

muricula 5y ago

The Linux Kernel development process is old-fashioned and there are lot of particular processes and conventions which make submitting a patch difficult. Also, if you use gmail with mutt to submit a patch, you have to change your email preferences to make gmail less secure[1]. It would be nice to have a friendlier way to contribute to the kernel, and a GitHub bridge seems like a good idea. [1]: https://medium.com/@crhenr/submitting-your-first-patch-to-the-linux-kernel-e81d2541fac6 https://medium.com/@crhenr/submitting-your-first-patch-to-th...

andrewchambers 5y ago
This is google imposed FUD to exercise control over users. They didn't need to design like that, but they want to make it hard to use things that are not google controlled.
- judge2020 5y ago
  IMAP/SMTP access with only your password is extremely insecure. Especially as most non-techie humans don’t use a password manager or even a strong password.
  - andrewchambers 5y ago
    Yes, but google could easily support per application passwords. They just don't want to... in fact, they used to and removed it. They could also invest in other ways to make existing workflows work securely instead of imposing their own ones.
    - judge2020 5y ago
      Sounds like oauth, which is an open standard.
      - jeroenhd 5y ago
        OAuth is far from standard in email. Google is the only company I know of that uses it for email. Per-application passwords are static passwords you generate for special applications. This way, the standard IMAP/SMTP logins will work, but a leaked password does not expose your entire Google account, only the email part. It also allows revocation of one application without re-entering your password on every device. It works flawlessly for many services, and Google supports/supported it as well. Using it just flags/flagged your account as "insecure" for some reason. Probably because they want you to use their propietary OAuth flow where they have more control over your software.

SkyMarshal 5y ago

All this research and not a single mention of Source Hut? Source Hut is designed to be a web-based interface to Git, but which uses Git's built-in email-based patch workflow instead of some proprietary interface like Github. It seems close to what they're looking for, and relatively easily hackable if missing anything they need. https://sourcehut.org/ https://sourcehut.org/ Good writeup on project philosophy: https://drewdevault.com/2018/11/15/sr.ht-general-availability.html https://drewdevault.com/2018/11/15/sr.ht-general-availabilit...

goodpoint 5y ago
Indeed, SourceHut would be an excellent choice for the kernel workflow.
- stavros 5y ago
  Wait, why do I keep pronouncing it "Sir Hat"?
  - SkyMarshal 5y ago
    Drew originally called it Sir Hat, before changing it to Source Hut: https://drewdevault.com/2018/11/15/sr.ht-general-availability.html https://drewdevault.com/2018/11/15/sr.ht-general-availabilit... https://news.ycombinator.com/item?id=18930554 https://news.ycombinator.com/item?id=18930554 https://news.ycombinator.com/item?id=19100986 https://news.ycombinator.com/item?id=19100986
    - stavros 5y ago
      Ahh, thanks, so I didn't make it up!
      - deleted 5y ago
        [deleted]
      - deleted 5y ago
        [deleted]

beprogrammed 5y ago

Looking at the sheer number of garbage/troll pull requests to Torvalds repo on GitHub makes me understand the resistance to this. You could imagine the constant flow of drive-by spam PR's you would be getting.

thatsabadidea 5y ago

Embrace, Extend, Extinguish No thanks.

geenat 5y ago

Bad idea. Distributed development ensures the kernel is difficult to corrupt or destroy. git was designed for this purpose. If a dev cannot be bothered to learn the distributed process, they should not be submitting code to the kernel. No corporation such as github, can be trusted with so much power. +1 respect to Linus as usual.

arp242 5y ago
No one is talking about moving Linux to GitHub.