From: Jason Gunthorpe <jgg@ziepe.ca>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Joe Perches <joe@perches.com>, Alex Elder <elder@ieee.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Dan Carpenter <dan.carpenter@linaro.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mark Brown <broonie@kernel.org>,
users@linux.kernel.org, ksummit@lists.linux.dev
Subject: Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org
Date: Thu, 9 Nov 2023 19:16:33 -0400 [thread overview]
Message-ID: <20231109231633.GI4634@ziepe.ca> (raw)
In-Reply-To: <20231109-soft-anaconda-of-passion-5157c7@nitro>
On Thu, Nov 09, 2023 at 02:38:58PM -0500, Konstantin Ryabitsev wrote:
> On Thu, Nov 09, 2023 at 11:11:08AM -0800, Joe Perches wrote:
> > > > My input is that whatever the outcome of all this discussion, please
> > > > define it as policy and have get_maintainer.pl implement it. I don't
> > > > want to have to think too hard about who *should* be included (beyond
> > > > people I already know).
> > >
> > > Yes, I fully agree with you -- people shouldn't need to know where the patches
> > > should be going. The tooling should decide this for them, and I want to change
> > > the tooling so that it no longer includes linux-kernel@vger on everything,
> > > only on patches without any other mailing list matches.
> >
> > Relatively easy to do, but what about your original request/suggestion
> > to use patches@lists.linux.dev ?
>
> Happy to go that route, just need to get the buy-in from everyone, which I
> intend to bring up at the maintainers summit. My proposed course of action
> is:
>
> 1. Update get_maintainer.pl so that linux-kernel@vger.kernel.org is no longer
> added on "THE REST" fall-through, unless there are no other L: entries that
> matched.
> 2. Add functionality to public-inbox to provide RSS feeds for "new topics" and
> "hot topics" that would allow following individual lists and the /all/
> aggregator. This is under discussion on the public-inbox meta list [1], so
> there is no final decision on this being included.
> 3. Figure out the best way to specify the "always-cc" address that should be
> always included by get_maintainer, either via MAINTAINERS, or via some kind
> of dot-file. Maybe just have this in MAINTAINERS:
>
> ALWAYS CC
> L: patches@lists.linux.dev
Is it possible you could do this on the backend and automatically
route all patches send to any mailing list to this list?
> I think this should gradually improve the linux-kernel mailing list to the
> point where most people will start reading it again.
From what I understood of this discussion the people who were using it
actually did seem to want the entire firehose of email? Removing
traffic from linux-kernel seems like the opposite of that?
How about getting people to move to an actual fire hose and then
scaling back linux-kernel until it can be retired? You were talking
about a flexible POP3 service or something...
Personally I've been using lei along with the "dfn" search. It seems
to work OK. Though lei itself is a bit of a bear.
It would be neat to be able to get some more targetted things like a
query that matches all pull request to Linus, for instance. That would
be an interesting virtual mailing list to read to keep aware of
things.
I don't know if it has been said enough but the entire lore
infrastructure has been very transformative for how, at least I,
work. It is fantastic having a reliable and robust archive.
Jason
next prev parent reply other threads:[~2023-11-09 23:16 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 15:33 RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org Konstantin Ryabitsev
2023-11-06 15:43 ` Joe Perches
2023-11-06 15:52 ` Borislav Petkov
2023-11-06 16:05 ` [workflows]RFC: " Steven Rostedt
2023-11-06 16:29 ` Miquel Raynal
2023-11-06 17:45 ` Konstantin Ryabitsev
2023-11-08 16:19 ` Joe Perches
2023-11-08 16:44 ` Mark Brown
2023-11-08 18:16 ` Joe Perches
2023-11-08 19:04 ` Steven Rostedt
2023-11-08 19:14 ` Joe Perches
2023-11-08 19:34 ` Steven Rostedt
2023-11-08 20:07 ` [workflows]Re: " Steven Rostedt
2023-11-08 20:14 ` Joe Perches
2023-11-08 20:36 ` Joe Perches
2023-11-08 20:49 ` Joe Perches
2023-11-08 20:56 ` Steven Rostedt
2023-11-08 21:04 ` Konstantin Ryabitsev
2023-11-08 21:11 ` Steven Rostedt
2023-11-08 20:41 ` Joe Perches
2023-11-09 11:21 ` Mark Brown
2023-11-09 11:29 ` Laurent Pinchart
2023-11-09 8:32 ` Dan Carpenter
2023-11-09 9:27 ` Laurent Pinchart
2023-11-09 17:14 ` Alex Elder
2023-11-09 17:25 ` Konstantin Ryabitsev
2023-11-09 19:11 ` Joe Perches
2023-11-09 19:38 ` Konstantin Ryabitsev
2023-11-09 23:16 ` Jason Gunthorpe [this message]
2023-11-10 0:56 ` Linus Torvalds
2023-11-10 17:04 ` Jakub Kicinski
2023-11-10 17:24 ` Konstantin Ryabitsev
2023-11-10 17:55 ` Jakub Kicinski
2023-11-10 17:24 ` Rob Herring
2023-11-10 18:04 ` Jakub Kicinski
2023-11-09 15:51 ` Steven Rostedt
2023-11-09 16:08 ` Laurent Pinchart
2023-11-09 16:16 ` Steven Rostedt
2023-11-06 16:11 ` RFC: " Eric W. Biederman
2023-11-06 17:05 ` Christoph Hellwig
2023-11-06 17:41 ` Konstantin Ryabitsev
2023-11-09 3:55 ` Ian Kelling
2023-11-11 16:57 ` Theodore Ts'o
2023-11-07 4:04 ` Willy Tarreau
2023-11-06 17:21 ` Eric Wong
2023-11-06 17:56 ` Eric W. Biederman
2023-11-09 14:24 ` Naveen N Rao
2023-11-06 17:23 ` Richard Weinberger
2023-11-06 20:52 ` Randy Dunlap
2023-11-06 21:37 ` Jakub Kicinski
2023-11-06 22:52 ` Pavel Machek
2023-11-07 9:18 ` Paolo Bonzini
2023-11-07 10:15 ` Laurent Pinchart
2023-11-07 10:42 ` Greg KH
2023-11-07 12:14 ` Pratyush Yadav
2023-11-07 12:47 ` Julia Lawall
2023-11-07 13:18 ` Dan Carpenter
2023-11-07 13:23 ` Pratyush Yadav
2023-11-07 16:35 ` Konstantin Ryabitsev
2023-11-07 16:43 ` Paolo Bonzini
2023-11-07 16:51 ` Konstantin Ryabitsev
2023-11-10 10:01 ` Paolo Bonzini
2023-11-07 10:47 ` Mark Brown
2023-11-07 13:24 ` Dan Carpenter
2023-11-08 20:04 ` Bird, Tim
2023-11-08 21:03 ` Luck, Tony
2023-11-08 21:04 ` James Bottomley
2023-11-08 21:18 ` Johannes Berg
2023-11-08 21:30 ` Rob Herring
2023-11-21 14:53 ` Joe Perches
2023-11-21 18:08 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231109231633.GI4634@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=broonie@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=elder@ieee.org \
--cc=joe@perches.com \
--cc=konstantin@linuxfoundation.org \
--cc=ksummit@lists.linux.dev \
--cc=laurent.pinchart@ideasonboard.com \
--cc=rostedt@goodmis.org \
--cc=users@linux.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.