3 ms·

Not everything can be broken down into 5 line patches. Some of the bigger features need bigger code. You can look at the impact radius and see if the patch is b

by vaidhy 2y ago

Not everything can be broken down into 5 line patches. Some of the bigger features need bigger code. You can look at the impact radius and see if the patch is behind a feature flag to make a decision. In this case, it seems like it is elective and does not have any changes beyond what is self-contained.

macNchz 2y ago
I don’t follow the Linux kernel development process closely, but on most projects—open source or proprietary—that I’ve been involved in, dropping a big diff without having proposed or discussed anything about it beforehand would have been fairly unwelcome, even if it’s something that would be infeasible to break down smaller. I’d also argue that even quite substantial changes can be made with incremental patches, if you choose to do so.
- raverbashing 2y ago
  There had probably been a lot of discussion in the background The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof Also do you know what would make it much easier to review long changes? Not using email patches But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home.goodmis.org/ https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
  - bonzini 2y ago
    > Not using email patches GitHub issues with "load 450 hidden comments" on it? No threads, no comparisons between multiple submissions of the same patch, changes from rebasing impossible to separate from everything else? Having to drop anyway to the command line to merge a subset that has been reviewed? Encouraging squash merging makes it easier to work with long changes? Email is complex and bare bones, but GitHub/GitLab reviews are a dumpster fire for anything that isn't trivial.
    - raverbashing 2y ago
      Try modern/patched versions of Gerrit, I'm sure Linus could tune it to his preference And I agree, GH has several issues
      - kashyapc 2y ago
        I've used Gerrit myself for nearly 10 years. I recognize it's strengths and like it for what it does. I also am comfortable with mailing lists and Git Hub and Git Lab. I've lived in "both worlds". IIUC, the Kernel project doesn't want to use it because of the single-point-of-failure argument and other federation issues. Once the "main" Gerrit instance is down, suddenly it's become a massive liability. This[1] is good context from the kernel.org administrator, Konstantin Ryabitsev: "From my perspective, there are several camps clashing when it comes to the kernel development model. One is people who are (rightfully) pointing out that using the mailing lists was fine 20 years ago, but the world of software development has vastly moved on to forges. "The other camp is people who (also rightfully) point out that kernel development has always been decentralized and we should resist all attempts to get ourselves into a position where Linux is dependent on any single Benevolent Entity (Github, Gitlab, LF, kernel.org, etc), because this would give that entity too much political or commercial control or, at the very least, introduce SPoFs. [...]" [1] https://lore.kernel.org/rust-for-linux/20250207-mature-pastel-rottweiler-e6dbd9@lemur/ https://lore.kernel.org/rust-for-linux/20250207-mature-paste...
        raverbashing 2y ago
        That's interesting, but I think the preocupation with SPoF to be overblown By that measure, kernel.org is a SPoF as well Maybe we can figure out a way to archive Gerrit discussions (offtopic note - don't upvote the comment you're responding to while you're commenting as you'll lose your comment)
        kashyapc 2y ago
        SPoF is not the only concern. Gerrit search is painful. You can't search the internet for a keyword that you wrote in v10 of some Gerrit patch, unlike on list-based workflows. Also, there's too much point-and-click for my taste, but I lived with it, as that's the tool chosen by that community. It's on me to adapt if I want to participate. (There are some ncurses-based tools, such as "gertty"[1]; but it was not reliable for me—the database crashed when I last tried it five years ago.) In contrast, I use Mutt for dealing with high-volume email-based projects with thousands of emails. It's blazingly fast, and an absolute delight to use—particularly when you're dealing with lists that run like a fire-hose. It gives a good productivity boost. I'm not saying, "don't drag me out of my email cave". I'm totally happy to adapt; I did live in "both worlds" :-) [1] https://opendev.org/ttygroup/gertty https://opendev.org/ttygroup/gertty
  - mmooss 2y ago
    Also see: https://lore.kernel.org/rust-for-linux/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
    - raverbashing 2y ago
      That's a great post, and also the presentation linked there is very interesting and hints at some of the issues (though I disagree with some of the prescriptions there) Yes, the model is not scaling. Yes the current model is turning people away from contributing I don't think linux itself is risking extinction, but someday the last person in an IRC channel will turn the lights off and I wonder if then they will think about what could they have done better and why don't people care about finicky buildsystems with liberal use of M4. Probably not.
  - account42 2y ago
    > There had probably been a lot of discussion in the background If that were the case then the patch would have a lot more CCs.
f1shy 2y ago
Then you have to discuss first, before throwing tousands of lines of code at somebody.

by vaidhy 2y ago

macNchz 2y ago

I don’t follow the Linux kernel development process closely, but on most projects—open source or proprietary—that I’ve been involved in, dropping a big diff without having proposed or discussed anything about it beforehand would have been fairly unwelcome, even if it’s something that would be infeasible to break down smaller. I’d also argue that even quite substantial changes can be made with incremental patches, if you choose to do so.

raverbashing 2y ago
There had probably been a lot of discussion in the background The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof Also do you know what would make it much easier to review long changes? Not using email patches But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home.goodmis.org/ https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
- bonzini 2y ago
  > Not using email patches GitHub issues with "load 450 hidden comments" on it? No threads, no comparisons between multiple submissions of the same patch, changes from rebasing impossible to separate from everything else? Having to drop anyway to the command line to merge a subset that has been reviewed? Encouraging squash merging makes it easier to work with long changes? Email is complex and bare bones, but GitHub/GitLab reviews are a dumpster fire for anything that isn't trivial.
  - raverbashing 2y ago
    Try modern/patched versions of Gerrit, I'm sure Linus could tune it to his preference And I agree, GH has several issues
    - kashyapc 2y ago
      I've used Gerrit myself for nearly 10 years. I recognize it's strengths and like it for what it does. I also am comfortable with mailing lists and Git Hub and Git Lab. I've lived in "both worlds". IIUC, the Kernel project doesn't want to use it because of the single-point-of-failure argument and other federation issues. Once the "main" Gerrit instance is down, suddenly it's become a massive liability. This[1] is good context from the kernel.org administrator, Konstantin Ryabitsev: "From my perspective, there are several camps clashing when it comes to the kernel development model. One is people who are (rightfully) pointing out that using the mailing lists was fine 20 years ago, but the world of software development has vastly moved on to forges. "The other camp is people who (also rightfully) point out that kernel development has always been decentralized and we should resist all attempts to get ourselves into a position where Linux is dependent on any single Benevolent Entity (Github, Gitlab, LF, kernel.org, etc), because this would give that entity too much political or commercial control or, at the very least, introduce SPoFs. [...]" [1] https://lore.kernel.org/rust-for-linux/20250207-mature-pastel-rottweiler-e6dbd9@lemur/ https://lore.kernel.org/rust-for-linux/20250207-mature-paste...
      - raverbashing 2y ago
        That's interesting, but I think the preocupation with SPoF to be overblown By that measure, kernel.org is a SPoF as well Maybe we can figure out a way to archive Gerrit discussions (offtopic note - don't upvote the comment you're responding to while you're commenting as you'll lose your comment)
        kashyapc 2y ago
        SPoF is not the only concern. Gerrit search is painful. You can't search the internet for a keyword that you wrote in v10 of some Gerrit patch, unlike on list-based workflows. Also, there's too much point-and-click for my taste, but I lived with it, as that's the tool chosen by that community. It's on me to adapt if I want to participate. (There are some ncurses-based tools, such as "gertty"[1]; but it was not reliable for me—the database crashed when I last tried it five years ago.) In contrast, I use Mutt for dealing with high-volume email-based projects with thousands of emails. It's blazingly fast, and an absolute delight to use—particularly when you're dealing with lists that run like a fire-hose. It gives a good productivity boost. I'm not saying, "don't drag me out of my email cave". I'm totally happy to adapt; I did live in "both worlds" :-) [1] https://opendev.org/ttygroup/gertty https://opendev.org/ttygroup/gertty
- mmooss 2y ago
  Also see: https://lore.kernel.org/rust-for-linux/20250208204416.GL1130956@mit.edu/ https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
  - raverbashing 2y ago
    That's a great post, and also the presentation linked there is very interesting and hints at some of the issues (though I disagree with some of the prescriptions there) Yes, the model is not scaling. Yes the current model is turning people away from contributing I don't think linux itself is risking extinction, but someday the last person in an IRC channel will turn the lights off and I wonder if then they will think about what could they have done better and why don't people care about finicky buildsystems with liberal use of M4. Probably not.
- account42 2y ago
  > There had probably been a lot of discussion in the background If that were the case then the patch would have a lot more CCs.

f1shy 2y ago

Then you have to discuss first, before throwing tousands of lines of code at somebody.