8 ms·
Reducing patch postings to Linux-kernel
- zozbot234 3y agoLooks like patches@ will be the new linux-kernel@, except that you won't be allowed to subscribe to it from big e-mail providers. Makes some sense, but wouldn't it be a lot simpler to just force every gmail subscriber to digest-mode where they just get a single e-mail per day (or even week/month), and tell them to use separate tools if they want to interact w/ the list?
- bombcar 3y agoIt seems this kind of thing would be something that Google would be exceptionally well placed to handle, because it's multiple identical copies of the email, which they should be able to store once and be done with it.
- Macha 3y agoI mean, sure if you're ok moving your mailing list to the not-actually-maintained Google Groups, I bet you wouldn't have gmail deliverability issues.
- KennyBlanken 3y agoYou'd think so, and yet several google group email lists I'm on are routinely flagged by gmail as being spam.
- fuzzy2 3y agoI always wondered how managing patches/patchsets using mail could scale. Now we know: It does not. I believe this calls not for a separate mailing list but a proper solution, whatever that might be.
- yakubin 3y agoThe problem here is that lots of patches are sent to too many people. Same will happen if you CC a mailing list with many subscribers in patches sent to Gerrit[1] or GitHub for a vibrant project. People will just start ignoring those notifications. It’s not about the tool. [1]: Speaking as a Gerrit fan.
- KennyBlanken 3y agoThe problem would be easily solved by: 1)Requiring the patch be posted online somewhere, not in the email message as an attachment. Criteria could be set, such as "must be via https, and something that will handle the volume of hits without becoming unreachable due to insufficient quota, server resources, or quota." Or set up a patch hosting server. Etc. 2)Dividing the kernel into major categories like every other major open source software project, and having patch lists for those categories. The main list should only be for announcements and discussions that require a broad audience.
- CuriousCosmic 3y ago> 2)Dividing the kernel into major categories like every other major open source software project, and having patch lists for those categories. The main list should only be for announcements and discussions that require a broad audience. Uhhhh the linux kernel mailing list is made up of at least a hundred separate mailing lists with development happening on the more specific mailing lists and a focus on maintaining/integration occurring on the more general lists.
- seba_dos1 3y agoDid you expect a HN commenter to actually research the thing they're commenting on? :P
- TylerE 3y agoMailing lists are like XML. Whatever the original problem was, you now have two problems.
- XorNot 3y agoIsn't the primary and possibly only objection to GitHub PRs just that they don't allow individual commit commenting?
- mdaniel 3y agoGH for sure allows commentary on individual commits (e.g. <https://github.com/torvalds/linux/commit/23816724fdbd47c28bc998866fd7bc5ad9f0e535#all_commit_comments https://github.com/torvalds/linux/commit/23816724fdbd47c28bc...>) but they do not automatically roll up to the top-level PR view (since, how would that work with cherry-picks: it shows up in every PR? what if, as is more likely, the line were superseded in a subsequent commit?)
- seba_dos1 3y agoHow are cherry-picks relevant? Cherry-picking creates completely separate and topologically unrelated commits. GitLab handles comments on commits within MRs pretty well. It still doesn't make it adequate for projects like Linux though.
- CuriousCosmic 3y agoGithub PRs do not make it easy for you to sign merge commits. It's possible in gitlab to my knowledge but in github it's a pain in the ass. And github needlessly touches PR commits so that even if you could fast-forward merge/rebase the PR while keeping signatures in tact, github will still regenerate your commits, breaking the hashes and signatures.
- aseipp 3y agoNo, it's not enough. One of the most important features missing is that kernel developers will want the equivalent of `git range-diff` (i.e. the ability to compare two versions of a single commit which was submitted as part of a batch of commits) in the UX for code review purposes. The lack of this feature makes the entire thing a non-starter, both Github and Gitlab. That said, they have accepted some PRs on GitHub at the past at one point as an experiment IIRC. But no, the current features they want are not there. The only real practical alternative is probably something like Gerrit, which still probably is missing features they want, or to write their own patch review tool on top of lore.lkml.org and some other infra.
- tleb_ 3y agoWell it has scaled up until now, which is a sign it could fit the scale of almost all software projects.
- candiddevmike 3y agoWonder if this will help reduce the amount of bikeshedding in PRs
- mtillman 3y agoI don't think I've ever looked at Maintainers before today. "THE REST" is how I'd like my team to remember me. https://www.kernel.org/doc/linux/MAINTAINERS https://www.kernel.org/doc/linux/MAINTAINERS
- titaniumtown 3y agoI've never looked at that list before either. How interesting.
- seba_dos1 3y agoEveryone who contributes is required to look at that list, either directly or indirectly via helper scripts. If you don't contribute, then well, it's completely irrelevant to you anyway.
- AeroNotix 3y agoI would love it if Linus took on email, much like he did with source control management and operating systems - built a set of working principles and the community continued that work.
- TylerE 3y agoIf it's anything like git, that might finally kill email for good. (and I'd say a happy GOOD RIDDANCE!)
- zoobab 3y ago"kill email for good" Kill it with fire, a protocol that is easily spyable, not ready for our days of mass surveillance.
- gumby 3y ago> I'd say a happy GOOD RIDDANCE! Why? It's vastly more useful to Discord, Slack, etc and highly amenable to automation in ways they are not -- you can even write your own client!
- insanitybit 3y agoThere's one feature of Discord and Slack that I like - no one can fucking talk to me unless I invite them. I'm so sick of communication systems where random people can contact me. Phones are worse, but email is quite bad. I've just created a new email because the one I've been using for the last 15 years is simply impossible to manage, with the constant, unsolicited spam.
- ajsnigrutin 3y agoSpam filters are great... even if you have none. "sorry, spam filter ate your mail" is an excuse noone really questions.
- gumby 3y agoIt's pretty trivial to set up a list of people allowed into your inbox. Maybe not with one of those consumer products like aol or gmail, but I mean seriously...!