[HN Gopher] Reducing patch postings to Linux-kernel
       ___________________________________________________________________
        
       Reducing patch postings to Linux-kernel
        
       Author : dezgeg
       Score  : 54 points
       Date   : 2023-11-09 13:24 UTC (9 hours ago)
        
 (HTM) web link (lwn.net)
 (TXT) w3m dump (lwn.net)
        
       | zozbot234 wrote:
       | Looks 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 wrote:
       | It 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 wrote:
         | I 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.
        
       | fuzzy2 wrote:
       | I 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 wrote:
         | The 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 wrote:
           | The 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.
        
         | TylerE wrote:
         | Mailing lists are like XML. Whatever the original problem was,
         | you now have two problems.
        
         | XorNot wrote:
         | Isn't the primary and possibly only objection to GitHub PRs
         | just that they don't allow individual commit commenting?
        
           | mdaniel wrote:
           | GH for sure allows commentary on individual commits (e.g. <ht
           | tps://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?)
        
       | candiddevmike wrote:
       | Wonder if this will help reduce the amount of bikeshedding in PRs
        
       | mtillman wrote:
       | I 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
        
         | titaniumtown wrote:
         | I've never looked at that list before either. How interesting.
        
       | AeroNotix wrote:
       | I 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 wrote:
         | If it's anything like git, that might finally kill email for
         | good. (and I'd say a happy GOOD RIDDANCE!)
        
           | gumby wrote:
           | > 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 wrote:
             | There'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 wrote:
               | Spam filters are great... even if you have none. "sorry,
               | spam filter ate your mail" is an excuse noone really
               | questions.
        
       ___________________________________________________________________
       (page generated 2023-11-09 23:00 UTC)