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.
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).
I submitted some changes a couple years ago and something named "Hulk Robot" at Huawei found my change didn't build with a certain kernel config, and sent a patch to fix. I think there's a lot of distributed checking going on even if kernel.org doesn't have an official pipeline or unit testing.
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 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.
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.
I think part of the appeal of git{hub,lab} is that the ones who won't want to figure out the email workflow are mostly there; there's no friction of having to sign up for yet another forge. sourcehut users are probably more likely to be ok following the kernel's normal workflow.
True, though there are two parts to that - 1) easy web-based patch submission workflow, and 2) everyone is already on github (and to a lesser extent gitlab).
#1 is easily solvable in SourceHut by hacking up mod that adds web-based workflow. It's designed for that modifying.
#2 is less easily solved, but may not need to be, since it also serves as a something of a quality filter. Apparently Linus gets all manner of inane of pull requests to his github repo, so moving it to Source Hut might cut down on that a little bit.
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.
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).
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”.
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.
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.
> 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.
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.)
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) It's not complete though and definitely not ready for the kernel's use case at the moment.
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.
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.
> Also, if you use gmail with mutt to submit a patch, you have to change your email preferences to make gmail less secure[1].
According to the article, this is because mutt uses IMAP, and needs to use password authentication (which might not even be accurate anymore). This has nothing to do with kernel development, beyond that some kernel developers like to use mutt as an email client.
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.
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.
Then I tried to use it again and lots of the menus the support pages referenced were no longer present. It was an endless cycle of broken links and features being hidden deeper and deeper in menus.
If that haven't removed it (I thought they had), it kind of made the intention clear to me.
That's just Google doing their usual best at designing UIs and documenting things. It's like watching your 5-year old do their best "helping" doing housework. Cute, but not actually very helpful.
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.
In a way, server providers prefer it as (in theory) users' long term credentials don't end up stored locally in plain text. A revocable per application token is used instead, and they can trace that back to a specific application or developer registration.
That it trains users it's ok to enter passwords in bespoke web views using abnormal or no clear URL view is a big issue though in my opinion - I've never liked flows that encourage entering passwords into web browsers you didn't open yourself, let alone ones provided by third party software, which can capture anything happening within the app itself.
You could imagine the constant flow of drive-by spam PR's you would be getting.