RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Konstantin Ryabitsev]

Hello, all:

About 70% of all vger traffic is linux-kernel@vger.kernel.org ("LKML"), which
is explained by the following 2 facts:

1. There are ~2900 subscribers to that list
2. It is added to all patches because it has "F: *" in MAINTAINERS

In the past month alone that list received 33,000 posts, which translates to
about 3.1 million messages delivered daily. This has pretty critical
downsides:

- due to the sheer volume of messages, LKML is generally seen as useless for
  holding any actual discussions
- people tend to subscribe gmail accounts to it and then filter out what they
  don't want
- due to gmail's quota policies, this generally results in anywhere from 50K to
  200K messages stuck in the queue all trying to deliver to gmail and being
  deferred with "this account is receiving too much mail"

For this reason, I propose switching the "F: *" entry in MAINTAINERS 
("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
in the following important aspects:

- it allows unrestricted posting, but
- all subscriptions must be pre-moderated, with the goal to only allow bot
  accounts to receive patches sent to that list (e.g. currently only the 0-day
  bot is subscribed)
- it is made available via public-inbox/lei and anonymous POP3, so those who
  want to still be able to have it delivered into their Gmail inbox will be
  able to set it up via POP3 import functionality (docs forthcoming)

This should improve the situation as follows:

- reduce the traffic seen on LKML to more reasonable volumes
- eventually get things to the point where sending something to
  linux-kernel@vger.kernel.org will be a reasonable action and not just
  screaming into the void (spitting into hurricane-force gale?)
- unclog the outgoing queues and speed up mail delivery for everyone

Please let me know your thoughts. I will also be happy to discuss this at the
upcoming kernel/maintainer summit.

-K

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

On Mon, 2023-11-06 at 10:33 -0500, Konstantin Ryabitsev wrote:
> I propose switching the "F: *" entry in MAINTAINERS 
> ("THE REST") to patches@lists.linux.dev instead.
[]
> Please let me know your thoughts.

I am somewhat responsible for these "THE REST" entries
and think this change is an excellent idea.

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Borislav Petkov]

On Mon, Nov 06, 2023 at 10:33:21AM -0500, Konstantin Ryabitsev wrote:
> Please let me know your thoughts. I will also be happy to discuss this at the
> upcoming kernel/maintainer summit.

Makes sense to me. We have always said that people should Cc: lkml for
archiving purposes so that we have the threads accessible somewhere
publicly and so that Link: tagging can work but that was before patches@
and lore happened. So as long as we can CC a ML in order to archive
discussions and submissions, we're good IMHO.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Steven Rostedt]

On Mon, 6 Nov 2023 10:33:21 -0500
Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

> For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> in the following important aspects:

As long as it doesn't affect those that have L: linux-kernel@vger.kernel.org

All core kernel changes should still go there.

 (Scheduler, timing, tracing, interrupts, etc)

-- Steve

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Eric W. Biederman]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> Hello, all:
>
> About 70% of all vger traffic is linux-kernel@vger.kernel.org ("LKML"), which
> is explained by the following 2 facts:
>
> 1. There are ~2900 subscribers to that list
> 2. It is added to all patches because it has "F: *" in MAINTAINERS
>
> In the past month alone that list received 33,000 posts, which translates to
> about 3.1 million messages delivered daily. This has pretty critical
> downsides:
>
> - due to the sheer volume of messages, LKML is generally seen as useless for
>   holding any actual discussions

I have never had that impression of LKML.

Of course I bring it into public-inbox locally on my end, as gmail's
capacity has always been too small.

I definitely periodically skim LKML and see what is there.

> - people tend to subscribe gmail accounts to it and then filter out what they
>   don't want
> - due to gmail's quota policies, this generally results in anywhere from 50K to
>   200K messages stuck in the queue all trying to deliver to gmail and being
>   deferred with "this account is receiving too much mail"
>
> For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> in the following important aspects:
>
> - it allows unrestricted posting, but
> - all subscriptions must be pre-moderated, with the goal to only allow bot
>   accounts to receive patches sent to that list (e.g. currently only the 0-day
>   bot is subscribed)
> - it is made available via public-inbox/lei and anonymous POP3, so those who
>   want to still be able to have it delivered into their Gmail inbox will be
>   able to set it up via POP3 import functionality (docs forthcoming)

Has anyone come up with a good way to mirror the public inbox git
repositories?

In the rare occasion when public inbox splits git repositories any
script that just mirrors the git repository silent stops working.

For something with LKML volume that is going to be significant.

So I would really appreciate it if before we have to start using public
inbox to get the full stream of everything, that there be an easy to
find commonly available script that makes it easy to mirror an entire
public inbox mailbox.

Eric

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Miquel Raynal]

Hello Konstantin,

rostedt@goodmis.org wrote on Mon, 6 Nov 2023 11:05:47 -0500:

> On Mon, 6 Nov 2023 10:33:21 -0500
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> 
> > For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> > ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> > in the following important aspects:  
> 
> As long as it doesn't affect those that have L: linux-kernel@vger.kernel.org
> 
> All core kernel changes should still go there.
> 
>  (Scheduler, timing, tracing, interrupts, etc)

There are many MAINTAINERS entries without explicit mailing-list which
are not really 'core kernel' areas. If we consider
patches@lists.linux.dev as an archive-only list, then
maybe get_maintainers.pl should somehow fallback to
linux-kernel@vger.kernel.org anyway when no list pops-up?

Thanks,
Miquèl

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Christoph Hellwig]

On Mon, Nov 06, 2023 at 10:11:48AM -0600, Eric W. Biederman wrote:
> > - due to the sheer volume of messages, LKML is generally seen as useless for
> >   holding any actual discussions
> 
> I have never had that impression of LKML.

Same here, I am actually reading through lkml, although superficially
skipping over some bits, and definitively starting discussions there.

Restricting access to the new lkml is not acceptable.  How about
restricting access to all lists for gmail addresses if gmail is so
broken?

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Eric Wong]

"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> Has anyone come up with a good way to mirror the public inbox git
> repositories?
> 
> In the rare occasion when public inbox splits git repositories any
> script that just mirrors the git repository silent stops working.

public-inbox-clone + public-inbox-fetch in released versions
of public-inbox work for mirroring individual inboxes.


public-inbox-clone for 2.0 (WIP in https://80x24.org/public-inbox.git )
can mirror multiple inboxes at once using grokmirror manifests
(no need for -fetch).

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Konstantin Ryabitsev" <konstantin@linuxfoundation.org>
> - due to the sheer volume of messages, LKML is generally seen as useless for
>  holding any actual discussions

I disagree. Of course I'm unable to follow all mail but I regularly
browse LKML to see what's going on.
Without LKML I'd have to subscribe to hundreds of subsystem specific
mailing lists for no reason.

Thanks,
//richard

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Konstantin Ryabitsev]

On Mon, Nov 06, 2023 at 09:05:12AM -0800, Christoph Hellwig wrote:
> > > - due to the sheer volume of messages, LKML is generally seen as useless for
> > >   holding any actual discussions
> > 
> > I have never had that impression of LKML.
> 
> Same here, I am actually reading through lkml, although superficially
> skipping over some bits, and definitively starting discussions there.

Hence my use of the word "generally."

> Restricting access to the new lkml is not acceptable.

It's not the "new lkml" -- the LKML is still there, it would just no longer be
a dumping ground for copies of all patches.

I also intentionally wrote "pre-moderated" instead of "restricted."
Subscriptions are still open, we just request a valid reason why someone wants
to receive copies of all patches.

> How about restricting access to all lists for gmail addresses if gmail is so
> broken?

Today it's gmail, tomorrow it's something else. Just a month ago all services
using outlook.com were broken for days:
https://learn.microsoft.com/en-us/answers/questions/1388775/outlook-com-servers-tells-server-busy-please-try-a

All I want is to know is why someone wants to receive a copy of all patches
via SMTP when much more effective mechanisms to achieve the same are
available. If someone can provide a valid reason -- such as being a
high-profile maintainer -- then of course I'll be happy to let them subscribe.

-K

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Konstantin Ryabitsev]

On Mon, Nov 06, 2023 at 05:29:32PM +0100, Miquel Raynal wrote:
> > > For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> > > ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> > > in the following important aspects:  
> > 
> > As long as it doesn't affect those that have L: linux-kernel@vger.kernel.org
> > 
> > All core kernel changes should still go there.
> > 
> >  (Scheduler, timing, tracing, interrupts, etc)
> 
> There are many MAINTAINERS entries without explicit mailing-list which
> are not really 'core kernel' areas. If we consider
> patches@lists.linux.dev as an archive-only list, then
> maybe get_maintainers.pl should somehow fallback to
> linux-kernel@vger.kernel.org anyway when no list pops-up?

I'm happy if we disambiguate between "THE REST" and "ALWAYS CC" behaviours. If
"THE REST" only triggers when there are no matching L: entries, and "ALWAYS
CC" gets added on all mail regardless, that would achieve the same result that
I'm looking for.

-K

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Eric W. Biederman]

Eric Wong <e@80x24.org> writes:

> "Eric W. Biederman" <ebiederm@xmission.com> wrote:
>> Has anyone come up with a good way to mirror the public inbox git
>> repositories?
>> 
>> In the rare occasion when public inbox splits git repositories any
>> script that just mirrors the git repository silent stops working.
>
> public-inbox-clone + public-inbox-fetch in released versions
> of public-inbox work for mirroring individual inboxes.
>
>
> public-inbox-clone for 2.0 (WIP in https://80x24.org/public-inbox.git )
> can mirror multiple inboxes at once using grokmirror manifests
> (no need for -fetch).

Thanks I will take a look.

Eric

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Randy Dunlap]

On 11/6/23 09:23, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Konstantin Ryabitsev" <konstantin@linuxfoundation.org>
>> - due to the sheer volume of messages, LKML is generally seen as useless for
>>  holding any actual discussions
> 
> I disagree. Of course I'm unable to follow all mail but I regularly
> browse LKML to see what's going on.
> Without LKML I'd have to subscribe to hundreds of subsystem specific
> mailing lists for no reason.

Ack. LKML is my primary conduit for any kernel email -- instead of using
multiple mailing lists.

-- 
~Randy

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Jakub Kicinski]

On Mon, 6 Nov 2023 10:33:21 -0500 Konstantin Ryabitsev wrote:
> About 70% of all vger traffic is linux-kernel@vger.kernel.org ("LKML"), which
> is explained by the following 2 facts:
> 
> 1. There are ~2900 subscribers to that list
> 2. It is added to all patches because it has "F: *" in MAINTAINERS

For networking, at least, I think that there is a solid correlation
between being a noob and CCing LKML. I would be tempted to add at least:

X: drivers/net/*

to the "THE REST". That should knock off a few k emails. WDYT?

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

Hi!
> 
> About 70% of all vger traffic is linux-kernel@vger.kernel.org ("LKML"), which
> is explained by the following 2 facts:
> 
> 1. There are ~2900 subscribers to that list
> 2. It is added to all patches because it has "F: *" in MAINTAINERS
> 
> In the past month alone that list received 33,000 posts, which translates to
> about 3.1 million messages delivered daily. This has pretty critical
> downsides:
> 
> - due to the sheer volume of messages, LKML is generally seen as useless for
>   holding any actual discussions
> - people tend to subscribe gmail accounts to it and then filter out what they
>   don't want
> - due to gmail's quota policies, this generally results in anywhere from 50K to
>   200K messages stuck in the queue all trying to deliver to gmail and being
>   deferred with "this account is receiving too much mail"
> 
> For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> in the following important aspects:

How many patches are in "the rest" area? I don't think it is that
many, and I believe those should be broadcasted, as it is not clear
who should handle them. And lkml seems to be reasonable place for them
at the moment.

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Willy Tarreau]

On Mon, Nov 06, 2023 at 09:05:12AM -0800, Christoph Hellwig wrote:
> On Mon, Nov 06, 2023 at 10:11:48AM -0600, Eric W. Biederman wrote:
> > > - due to the sheer volume of messages, LKML is generally seen as useless for
> > >   holding any actual discussions
> > 
> > I have never had that impression of LKML.
> 
> Same here, I am actually reading through lkml, although superficially
> skipping over some bits, and definitively starting discussions there.

Same here. I used to have a procmail filter to deliver lkml to its own
box a decade ago and I figured that I lost contact with what was happening
so I removed that filter so that I move all these messages manually several
times a day after scrolling over them (a single key in mutt). This way
every day I can have a quick glance at all subjects there, that's how I
discover new topics, patch series, discussions etc. I think that a non
negligible number of LKML subscribers are there for this exact reason.

I would personally miss these messages if they would not be delivered
there anymore :-/ And I don't think that the situation would significantly
improve in the short term anyway due to this.

> Restricting access to the new lkml is not acceptable.  How about
> restricting access to all lists for gmail addresses if gmail is so
> broken?

Or even simpler, flush the queue very often and make it clear that gmail
is not a reliable recipiet for LKML. The trouble will self-regulate.

Just my two cents,
Willy

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Paolo Bonzini]

On 11/6/23 23:52, Pavel Machek wrote:
>> For this reason, I propose switching the "F: *" entry in MAINTAINERS
>> ("THE REST") topatches@lists.linux.dev  instead. This list differs from LKML
>> in the following important aspects:
> How many patches are in "the rest" area? I don't think it is that
> many, and I believe those should be broadcasted, as it is not clear
> who should handle them. And lkml seems to be reasonable place for them
> at the moment.

Indeed, I suspect that a lot of the traffic to LKML does not come from 
"THE REST", but rather from people using a git-send-email configuration like

	[sendemail]
	to = linux-kernel@vger.kernel.org

I'm afraid that having everyone switch this to patches@lists.linux.dev 
will take a looooong time.  Right now I import LKML via public-inbox for 
use by https://patchew.org/linux/, it doesn't include all messages but 
it's pretty close; the patches@lists.linux.dev mailing list by 
comparison hardly gets any message apart from Greg's stable kernel queues.

Paolo

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Laurent Pinchart]

On Tue, Nov 07, 2023 at 10:18:58AM +0100, Paolo Bonzini wrote:
> On 11/6/23 23:52, Pavel Machek wrote:
> >> For this reason, I propose switching the "F: *" entry in MAINTAINERS
> >> ("THE REST") topatches@lists.linux.dev  instead. This list differs from LKML
> >> in the following important aspects:
> >
> > How many patches are in "the rest" area? I don't think it is that
> > many, and I believe those should be broadcasted, as it is not clear
> > who should handle them. And lkml seems to be reasonable place for them
> > at the moment.
> 
> Indeed, I suspect that a lot of the traffic to LKML does not come from 
> "THE REST", but rather from people using a git-send-email configuration like
> 
> 	[sendemail]
> 	to = linux-kernel@vger.kernel.org

Do we document this as being a recommended git-send-email configuration
? That sounds horrible :-( Documentation/process/submitting-patches.rst
states

  linux-kernel@vger.kernel.org should be used by default for all
  patches, but the volume on that list has caused a number of developers
  to tune it out.  Please do not spam unrelated lists and unrelated
  people, though.

This should be updated, even if for the only reason that the text is
quite confusing (in my opinion at least, I'm not sure if it means LKML
should be used for all patches, or shouldn't).

To give another data point, balancing a bit the replies that expressed
surprise at Konstantin's point that LKML is generally seen as useless
for holding actual discussions, I do not follow LKML at all due to the
amount of mails that are not general discussions. It drowns the useful
information in noise for me.

> I'm afraid that having everyone switch this to patches@lists.linux.dev 
> will take a looooong time.  Right now I import LKML via public-inbox for 
> use by https://patchew.org/linux/, it doesn't include all messages but 
> it's pretty close; the patches@lists.linux.dev mailing list by 
> comparison hardly gets any message apart from Greg's stable kernel queues.

-- 
Regards,

Laurent Pinchart

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Greg KH]

On Tue, Nov 07, 2023 at 12:15:13PM +0200, Laurent Pinchart wrote:
> On Tue, Nov 07, 2023 at 10:18:58AM +0100, Paolo Bonzini wrote:
> > On 11/6/23 23:52, Pavel Machek wrote:
> > >> For this reason, I propose switching the "F: *" entry in MAINTAINERS
> > >> ("THE REST") topatches@lists.linux.dev  instead. This list differs from LKML
> > >> in the following important aspects:
> > >
> > > How many patches are in "the rest" area? I don't think it is that
> > > many, and I believe those should be broadcasted, as it is not clear
> > > who should handle them. And lkml seems to be reasonable place for them
> > > at the moment.
> > 
> > Indeed, I suspect that a lot of the traffic to LKML does not come from 
> > "THE REST", but rather from people using a git-send-email configuration like
> > 
> > 	[sendemail]
> > 	to = linux-kernel@vger.kernel.org
> 
> Do we document this as being a recommended git-send-email configuration
> ? That sounds horrible :-( Documentation/process/submitting-patches.rst
> states
> 
>   linux-kernel@vger.kernel.org should be used by default for all
>   patches, but the volume on that list has caused a number of developers
>   to tune it out.  Please do not spam unrelated lists and unrelated
>   people, though.
> 
> This should be updated, even if for the only reason that the text is
> quite confusing (in my opinion at least, I'm not sure if it means LKML
> should be used for all patches, or shouldn't).
> 
> To give another data point, balancing a bit the replies that expressed
> surprise at Konstantin's point that LKML is generally seen as useless
> for holding actual discussions, I do not follow LKML at all due to the
> amount of mails that are not general discussions. It drowns the useful
> information in noise for me.

I think changing the default so that our tools don't automatically point
to lkml will be the key.  For example, here's what get_maintainer.pl
says to do:

	$ ./scripts/get_maintainer.pl drivers/usb/Kconfig
	Greg Kroah-Hartman <gregkh@linuxfoundation.org> (supporter:USB SUBSYSTEM)
	linux-usb@vger.kernel.org (open list:USB SUBSYSTEM)
	linux-kernel@vger.kernel.org (open list)

Why, when we have a valid mailing list (linux-usb), should lkml also be
involved?  I think this patch changes this, which is a good thing and
should cut down on the overall size over time.

thanks,

greg k-h

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]

On Tue, Nov 07, 2023 at 10:18:58AM +0100, Paolo Bonzini wrote:

> Indeed, I suspect that a lot of the traffic to LKML does not come from "THE
> REST", but rather from people using a git-send-email configuration like

> 	[sendemail]
> 	to = linux-kernel@vger.kernel.org

> I'm afraid that having everyone switch this to patches@lists.linux.dev will
> take a looooong time.  Right now I import LKML via public-inbox for use by
> https://patchew.org/linux/, it doesn't include all messages but it's pretty
> close; the patches@lists.linux.dev mailing list by comparison hardly gets
> any message apart from Greg's stable kernel queues.

Note that get_maintainers.pl at some point started everyone to CC lkml
on everything, it's *much* more likely that people are picking things up
from there than that they've gone and made an explicit configuration
like this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Pratyush Yadav]

On Tue, Nov 07 2023, Laurent Pinchart wrote:

> On Tue, Nov 07, 2023 at 10:18:58AM +0100, Paolo Bonzini wrote:
>> On 11/6/23 23:52, Pavel Machek wrote:
>> >> For this reason, I propose switching the "F: *" entry in MAINTAINERS
>> >> ("THE REST") topatches@lists.linux.dev  instead. This list differs from LKML
>> >> in the following important aspects:
>> >
>> > How many patches are in "the rest" area? I don't think it is that
>> > many, and I believe those should be broadcasted, as it is not clear
>> > who should handle them. And lkml seems to be reasonable place for them
>> > at the moment.
>>
>> Indeed, I suspect that a lot of the traffic to LKML does not come from
>> "THE REST", but rather from people using a git-send-email configuration like
>>
>>       [sendemail]
>>       to = linux-kernel@vger.kernel.org

FWIW, I do not have this nor have I seen any of my colleagues ever have
this in their config. In the patches I send, lkml always comes from
get_maintainers.pl.

>
> Do we document this as being a recommended git-send-email configuration
> ? That sounds horrible :-( Documentation/process/submitting-patches.rst
> states
>
>   linux-kernel@vger.kernel.org should be used by default for all
>   patches, but the volume on that list has caused a number of developers
>   to tune it out.  Please do not spam unrelated lists and unrelated
>   people, though.
>
> This should be updated, even if for the only reason that the text is
> quite confusing (in my opinion at least, I'm not sure if it means LKML
> should be used for all patches, or shouldn't).
>
> To give another data point, balancing a bit the replies that expressed
> surprise at Konstantin's point that LKML is generally seen as useless
> for holding actual discussions, I do not follow LKML at all due to the
> amount of mails that are not general discussions. It drowns the useful
> information in noise for me.

Yes, same for me. In general, I find the mail volume on LKML to be too
large for me to subscribe to it. Of late I have been relying more and
more on public-inbox and lei to read and browse kernel mail.

-- 
Regards,
Pratyush Yadav

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Julia Lawall]

At various times, I have wanted to see the discussion that led up to a
commit, and LKML was the obvious place to go for that.  What will be the
approach to take in the future?

thanks,
julia

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Dan Carpenter]

On Tue, Nov 07, 2023 at 07:47:23AM -0500, Julia Lawall wrote:
> At various times, I have wanted to see the discussion that led up to a
> commit, and LKML was the obvious place to go for that.  What will be the
> approach to take in the future?

We'd still use lore.kernel.org and b4 and lei.

regards,
dan carpenter

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Pratyush Yadav]

On Tue, Nov 07 2023, Julia Lawall wrote:

> At various times, I have wanted to see the discussion that led up to a
> commit, and LKML was the obvious place to go for that.  What will be the
> approach to take in the future?

I use lei with lore.kernel.org/all for that. For example, say I want to
see the discussion behind b6094ac83dd4 ("mtd: spi-nor: core: Introduce
spi_nor_set_4byte_addr_mode()"). I run the below query (on lore or on
lei, whichever suits your workflow) [0]:

   s:mtd: spi-nor: core: Introduce spi_nor_set_4byte_addr_mode() 

I then get the emails associated with the patch. This also works for
patches that arrived before I subscribed to any of the mailing lists. So
I find this method to be more powerful and complete than subscribing to
mailing lists.

[0] I have written some bits of code to integrate lei with gnus which
makes it easy for me to quickly open and read email threads. In the
background, it essentially runs:

    lei q --no-save -O https://lore.kernel.org/all/ -o mboxrd:temp.mbox -t "s:mtd: spi-nor: core: Introduce spi_nor_set_4byte_addr_mode()"

which creates an mbox file with the results of the query. "-t" tells it
to fetch the whole thread of any email that matches this query. I then
create a gnus group from the mbox and read the emails. See the lei q man
page for more details: https://public-inbox.org/lei-q.html

Lei can do much more but right now this simple workflow works pretty
good for me.

-- 
Regards,
Pratyush Yadav

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Dan Carpenter]

It's interesting that you announced this on ksummit@lists.linux.dev
and didn't even bother CC'ing LKML.  That's what I do as well these days
for discussions that affect everyone.  The ksummit list is the defacto
list for general topics.

regards,
dan carpenter

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Konstantin Ryabitsev]

On Tue, Nov 07, 2023 at 07:47:23AM -0500, Julia Lawall wrote:
> At various times, I have wanted to see the discussion that led up to a
> commit, and LKML was the obvious place to go for that.  What will be the
> approach to take in the future?

I assume you're asking if following links to lkml.kernel.org/r/<msgid> is
still going to find the thread? If that's the case, then yes, it's really just
a redirect to lore.kernel.org/all/, which aggregates everything across all
lists indexed by lore.kernel.org.

You can similarly search in /all/ for the subjects matching commits if you
don't have a Link:.

In other words, this functionality is not affected by which list the patches
were sent to.

-K

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Paolo Bonzini]

On 11/7/23 17:35, Konstantin Ryabitsev wrote:
> I assume you're asking if following links to lkml.kernel.org/r/<msgid> 
> is still going to find the thread? If that's the case, then yes, it's 
> really just a redirect to lore.kernel.org/all/, which aggregates 
> everything across all lists indexed by lore.kernel.org. You can 
> similarly search in /all/ for the subjects matching commits if you don't 
> have a Link:. In other words, this functionality is not affected by 
> which list the patches were sent to.

What about _pulling_ all patches from public-inbox?  Right now the git 
repos under https://lore.kernel.org/lkml/ do not catch everything, but 
it's close enough.  There would be no https://lore.kernel.org/all/1.git/ 
and, even if there were, there is no easy way to filter out non-Linux 
projects.

Paolo

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Konstantin Ryabitsev]

On Tue, Nov 07, 2023 at 05:43:20PM +0100, Paolo Bonzini wrote:
> > I assume you're asking if following links to lkml.kernel.org/r/<msgid>
> > is still going to find the thread? If that's the case, then yes, it's
> > really just a redirect to lore.kernel.org/all/, which aggregates
> > everything across all lists indexed by lore.kernel.org. You can
> > similarly search in /all/ for the subjects matching commits if you don't
> > have a Link:. In other words, this functionality is not affected by
> > which list the patches were sent to.
> 
> What about _pulling_ all patches from public-inbox?  Right now the git repos
> under https://lore.kernel.org/lkml/ do not catch everything, but it's close
> enough.  There would be no https://lore.kernel.org/all/1.git/ and, even if
> there were, there is no easy way to filter out non-Linux projects.

Sorry, I'm not entirely sure what you're asking. You want to be able to
automatically retrieve all patches but only if they are related to the kernel?

-K

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

On Mon, 2023-11-06 at 11:05 -0500, Steven Rostedt wrote:
> On Mon, 6 Nov 2023 10:33:21 -0500
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> 
> > For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> > ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> > in the following important aspects:
> 
> As long as it doesn't affect those that have L: linux-kernel@vger.kernel.org
> 
> All core kernel changes should still go there.
> 
>  (Scheduler, timing, tracing, interrupts, etc)

If this is done, perhaps half or more of the lkml
mailing list entries in MAINTAINERS should be removed.

This grep shows all the section entries with
	L:	linux-kernel@vger.kernel.org
most of which seem not "core".

$ git grep -P -n "(?:^[\w][^:]|^L:\s*linux-kernel@vger.kernel.org)" MAINTAINERS | \
  grep -B1 linux-kernel | grep -v '^--' | grep -v ':L:'
MAINTAINERS:1382:ANDROID DRIVERS
MAINTAINERS:2357:ARM/Mediatek SoC support
MAINTAINERS:2881:ARM/TEXAS INSTRUMENT AEMIF/EMIF DRIVERS
MAINTAINERS:2896:ARM/TEXAS INSTRUMENT KEYSTONE CLOCK FRAMEWORK
MAINTAINERS:2902:ARM/TEXAS INSTRUMENT KEYSTONE CLOCKSOURCE
MAINTAINERS:2909:ARM/TEXAS INSTRUMENT KEYSTONE RESET DRIVER
MAINTAINERS:3318:ATOMIC INFRASTRUCTURE
MAINTAINERS:4192:BROADCOM BRCMSTB USB2 and USB3 PHY DRIVER
MAINTAINERS:4659:CANAAN/KENDRYTE K210 SOC RESET CONTROLLER DRIVER
MAINTAINERS:5119:CLOCKSOURCE, CLOCKEVENT DRIVERS
MAINTAINERS:5429:CPU HOTPLUG
MAINTAINERS:5821:DEBUGOBJECTS:
MAINTAINERS:6018:DEVICE COREDUMP (DEV_COREDUMP)
MAINTAINERS:6025:DEVICE DEPENDENCY HELPER SCRIPT
MAINTAINERS:6402:DPAA2 DATAPATH I/O (DPIO) DRIVER
MAINTAINERS:8004:EXTERNAL CONNECTOR SUBSYSTEM (EXTCON)
MAINTAINERS:8016:EXTRA BOOT CONFIG
MAINTAINERS:8232:FIRMWARE LOADER (request_firmware)
MAINTAINERS:8697:FUNCTION HOOKS (FTRACE)
MAINTAINERS:8730:FUTEX SUBSYSTEM
MAINTAINERS:8795:GENERIC ARCHITECTURE TOPOLOGY
MAINTAINERS:8802:GENERIC ENTRY CODE
MAINTAINERS:8915:GENERIC VDSO LIBRARY
MAINTAINERS:9460:HIGH-RESOLUTION TIMERS, CLOCKEVENTS
MAINTAINERS:9484:HIKEY960 ONBOARD USB GPIO HUB DRIVER
MAINTAINERS:9592:HISILICON PTT DRIVER
MAINTAINERS:9647:HISILICON SPMI CONTROLLER DRIVER FOR HIKEY 970
MAINTAINERS:9654:HISILICON SPMI PMIC DRIVER FOR HIKEY 6421v600
MAINTAINERS:9842:HYGON PROCESSOR SUPPORT
MAINTAINERS:10613:INTEL CPU family model numbers
MAINTAINERS:10820:INTEL MANAGEMENT ENGINE (mei)
MAINTAINERS:10951:INTEL STRATIX10 FIRMWARE DRIVERS
MAINTAINERS:11215:IRQ SUBSYSTEM
MAINTAINERS:11224:IRQCHIP DRIVERS
MAINTAINERS:11628:KERNEL USERMODE HELPER
MAINTAINERS:11906:KPROBES
MAINTAINERS:12307:LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM)
MAINTAINERS:12446:LOCKING PRIMITIVES
MAINTAINERS:12725:MAILBOX API
MAINTAINERS:12735:MAILBOX ARM MHUv2
MAINTAINERS:13059:MAXIM MAX20086 CAMERA POWER PROTECTOR DRIVER
MAINTAINERS:13072:MAXIM MAX77650 PMIC MFD DRIVER
MAINTAINERS:13093:MAXIM MAX77802 PMIC REGULATOR DEVICE DRIVER
MAINTAINERS:13117:MAXIM PMIC AND MUIC DRIVERS FOR EXYNOS BASED BOARDS
MAINTAINERS:13857:MEMBARRIER SUPPORT
MAINTAINERS:13876:MEMORY CONTROLLER DRIVERS
MAINTAINERS:14069:MICROCHIP AT91 USART MFD DRIVER
MAINTAINERS:14606:MODULE SUPPORT
MAINTAINERS:15278:NITRO ENCLAVES (NE)
MAINTAINERS:15290:NOHZ, DYNTICKS SUPPORT
MAINTAINERS:15581:NXP PTN5150A CC LOGIC AND EXTCON DRIVER
MAINTAINERS:15595:NXP SJA1105 ETHERNET SWITCH DRIVER
MAINTAINERS:16315:PADATA PARALLEL EXECUTION MECHANISM
MAINTAINERS:16952:PERFORMANCE EVENTS SUBSYSTEM
MAINTAINERS:17031:PIDFD API
MAINTAINERS:17290:POSIX CLOCKS and TIMERS
MAINTAINERS:17409:PROC FILESYSTEM
MAINTAINERS:17418:PROC SYSCTL
MAINTAINERS:17762:QORIQ DPAA2 FSL-MC BUS DRIVER
MAINTAINERS:18252:RDT - RESOURCE ALLOCATION
MAINTAINERS:18350:REGISTER MAP ABSTRACTION
MAINTAINERS:18561:RESTARTABLE SEQUENCES SUPPORT
MAINTAINERS:18775:ROHM MULTIFUNCTION BD9571MWV-M PMIC DEVICE DRIVERS
MAINTAINERS:19140:SAMSUNG MULTIFUNCTION PMIC DEVICE DRIVERS
MAINTAINERS:19251:SAMSUNG USB2 PHY DRIVER
MAINTAINERS:19275:SCHEDULER
MAINTAINERS:20458:SPMI SUBSYSTEM
MAINTAINERS:21799:TI KEYSTONE MULTICORE NAVIGATOR DRIVERS
MAINTAINERS:21884:TIMEKEEPING, CLOCKSOURCE CORE, NTP, ALARMTIMER
MAINTAINERS:21976:TORTURE-TEST MODULES
MAINTAINERS:22064:TRACING
MAINTAINERS:22080:TRACING MMIO ACCESSES (MMIOTRACE)
MAINTAINERS:22123:TTY LAYER AND SERIAL DRIVERS
MAINTAINERS:22219:UACCE ACCELERATOR FRAMEWORK
MAINTAINERS:22737:UUID HELPERS
MAINTAINERS:23222:VME SUBSYSTEM
MAINTAINERS:23232:VMWARE BALLOON DRIVER
MAINTAINERS:23275:VMWARE VMCI DRIVER
MAINTAINERS:23300:VMWARE VSOCK VMCI TRANSPORT DRIVER
MAINTAINERS:23314:VOLTAGE AND CURRENT REGULATOR FRAMEWORK
MAINTAINERS:23568:X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS
MAINTAINERS:23588:X86 ARCHITECTURE (32-BIT AND 64-BIT)
MAINTAINERS:23602:X86 ENTRY CODE
MAINTAINERS:23634:X86 MM
MAINTAINERS:23705:X86 VDSO
MAINTAINERS:24008:XILINX ZYNQMP PSGTR PHY DRIVER
MAINTAINERS:24021:XILLYBUS DRIVER
MAINTAINERS:24115:ZHAOXIN PROCESSOR SUPPORT
MAINTAINERS:24148:ZRAM COMPRESSED RAM BLOCK DEVICE DRVIER
MAINTAINERS:24190:THE REST

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On Wed, Nov 08, 2023 at 08:19:46AM -0800, Joe Perches wrote:
> On Mon, 2023-11-06 at 11:05 -0500, Steven Rostedt wrote:
> > Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

> > > For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> > > ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> > > in the following important aspects:

> > As long as it doesn't affect those that have L: linux-kernel@vger.kernel.org

> > All core kernel changes should still go there.

> >  (Scheduler, timing, tracing, interrupts, etc)

> If this is done, perhaps half or more of the lkml
> mailing list entries in MAINTAINERS should be removed.

> This grep shows all the section entries with
> 	L:	linux-kernel@vger.kernel.org
> most of which seem not "core".

The suggestion wasn't to use LKML exclusively for core changs but rather
to not have LKML added for everything that has a more specific list.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

On Wed, 2023-11-08 at 16:44 +0000, Mark Brown wrote:
> On Wed, Nov 08, 2023 at 08:19:46AM -0800, Joe Perches wrote:
> > On Mon, 2023-11-06 at 11:05 -0500, Steven Rostedt wrote:
> > > Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> 
> > > > For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> > > > ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> > > > in the following important aspects:
> 
> > > As long as it doesn't affect those that have L: linux-kernel@vger.kernel.org
> 
> > > All core kernel changes should still go there.
> 
> > >  (Scheduler, timing, tracing, interrupts, etc)
> 
> > If this is done, perhaps half or more of the lkml
> > mailing list entries in MAINTAINERS should be removed.
> 
> > This grep shows all the section entries with
> > 	L:	linux-kernel@vger.kernel.org
> > most of which seem not "core".
> 
> The suggestion wasn't to use LKML exclusively for core changs but rather
> to not have LKML added for everything that has a more specific list.

Likely you and I read Steven's suggestion differently.
Perhaps Steven wants to clarify.

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Steven Rostedt]

On Wed, 08 Nov 2023 10:16:15 -0800
Joe Perches <joe@perches.com> wrote:

> On Wed, 2023-11-08 at 16:44 +0000, Mark Brown wrote:
> > On Wed, Nov 08, 2023 at 08:19:46AM -0800, Joe Perches wrote:  
> > > On Mon, 2023-11-06 at 11:05 -0500, Steven Rostedt wrote:  
> > > > Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:  
> >   
> > > > > For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> > > > > ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> > > > > in the following important aspects:  
> >   
> > > > As long as it doesn't affect those that have L: linux-kernel@vger.kernel.org  
> >   
> > > > All core kernel changes should still go there.  
> >   
> > > >  (Scheduler, timing, tracing, interrupts, etc)  
> >   
> > > If this is done, perhaps half or more of the lkml
> > > mailing list entries in MAINTAINERS should be removed.  
> >   
> > > This grep shows all the section entries with
> > > 	L:	linux-kernel@vger.kernel.org
> > > most of which seem not "core".  
> > 
> > The suggestion wasn't to use LKML exclusively for core changs but rather
> > to not have LKML added for everything that has a more specific list.  
> 
> Likely you and I read Steven's suggestion differently.
> Perhaps Steven wants to clarify.

Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
but I prefer the discussions to be done on LKML.

-- Steve

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

On Wed, 2023-11-08 at 14:04 -0500, Steven Rostedt wrote:
> On Wed, 08 Nov 2023 10:16:15 -0800
> Joe Perches <joe@perches.com> wrote:
> 
> > On Wed, 2023-11-08 at 16:44 +0000, Mark Brown wrote:
> > > On Wed, Nov 08, 2023 at 08:19:46AM -0800, Joe Perches wrote:  
> > > > On Mon, 2023-11-06 at 11:05 -0500, Steven Rostedt wrote:  
> > > > > Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:  
> > >   
> > > > > > For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> > > > > > ("THE REST") to patches@lists.linux.dev instead. This list differs from LKML
> > > > > > in the following important aspects:  
> > >   
> > > > > As long as it doesn't affect those that have L: linux-kernel@vger.kernel.org  
> > >   
> > > > > All core kernel changes should still go there.  
> > >   
> > > > >  (Scheduler, timing, tracing, interrupts, etc)  
> > >   
> > > > If this is done, perhaps half or more of the lkml
> > > > mailing list entries in MAINTAINERS should be removed.  
> > >   
> > > > This grep shows all the section entries with
> > > > 	L:	linux-kernel@vger.kernel.org
> > > > most of which seem not "core".  
> > > 
> > > The suggestion wasn't to use LKML exclusively for core changs but rather
> > > to not have LKML added for everything that has a more specific list.  
> > 
> > Likely you and I read Steven's suggestion differently.
> > Perhaps Steven wants to clarify.
> 
> Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
> but I prefer the discussions to be done on LKML.

How would that work?  Especially with get_maintainer?

Are people are supposed to start discussions on lkml but
only send patches to a separate list?

What linkage would you expect to offer between a discussion
and a proposed patch?

Subject matching?  People adding Link: markings?

Both of those seem unlikely to be effective.

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Steven Rostedt]

On Wed, 08 Nov 2023 11:14:45 -0800
Joe Perches <joe@perches.com> wrote:

> > Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
> > but I prefer the discussions to be done on LKML.  
> 
> How would that work?  Especially with get_maintainer?

The way it works now. Just Cc both lists. What's the problem with that?

I use to only do discussions on LKML and have myself Cc'd (or Cc myself in
the discussions), but then I couldn't manage the patches from my inbox. So
I set up the mailing list and added that to be Cc'd too in MAINTAINERS, so
that everything goes to the other mailing list as well. That would then keep
the patches in patchwork, but the discussions would still be visible to the
general audience on LKML.


TRACING
M:      Steven Rostedt <rostedt@goodmis.org>
M:      Masami Hiramatsu <mhiramat@kernel.org>
L:      linux-kernel@vger.kernel.org
L:      linux-trace-kernel@vger.kernel.org
S:      Maintained


-- Steve

RE: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Bird, Tim]

> -----Original Message-----
> From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> For this reason, I propose switching the "F: *" entry in MAINTAINERS
> ("THE REST") to patches@lists.linux.dev instead.
...

> This should improve the situation as follows:
> 
> - reduce the traffic seen on LKML to more reasonable volumes
> - eventually get things to the point where sending something to
>   linux-kernel@vger.kernel.org will be a reasonable action and not just
>   screaming into the void (spitting into hurricane-force gale?)
> - unclog the outgoing queues and speed up mail delivery for everyone
> 
> Please let me know your thoughts. I will also be happy to discuss this at the
> upcoming kernel/maintainer summit.

The way I use LKML is to shove it to gmail (as many do), and then on the very
rare occasion when I see an item I want to respond to (that's copied both
to LKML and some other list I'm not subscribed to), I have an email in
my gmail folder I can respond to.

Is there a way to use b4, lei, lore, etc. for responding to mail on a list one is
not subscribed to?

I'll admit this is an extremely rare event, and it requires I periodically purge
my gmail LKML folder, so an alternate mechanism for this would be great.
 -- Tim
 

Re: [workflows]Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Steven Rostedt]

On Wed, 8 Nov 2023 14:34:47 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> I use to only do discussions on LKML and have myself Cc'd (or Cc myself in
> the discussions), but then I couldn't manage the patches from my inbox. So
> I set up the mailing list and added that to be Cc'd too in MAINTAINERS, so
> that everything goes to the other mailing list as well. That would then keep
> the patches in patchwork, but the discussions would still be visible to the
> general audience on LKML.

BTW, you have joined some of the discussions to these patches in the past.
Do you subscribe to all the other mailing lists in the MAINTAINERS file too?

If not, then you would not have been able to add your input to those
discussions.

-- Steve

Re: [workflows]Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

On Wed, 2023-11-08 at 15:07 -0500, Steven Rostedt wrote:
> BTW, you have joined some of the discussions to these patches in the past.
> Do you subscribe to all the other mailing lists in the MAINTAINERS file too?

Nope.

I'm not even subscribed to lkml and now rarely join discussions at all.

Basically I look at lore every now and again using keyword searches
then download messages of some threads manually.

Re: [workflows]Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

On Wed, 2023-11-08 at 12:14 -0800, Joe Perches wrote:
> On Wed, 2023-11-08 at 15:07 -0500, Steven Rostedt wrote:

<empty email?  evolution still sucks>

My sent email folder entry for this is:

On Wed, 2023-11-08 at 15:07 -0500, Steven Rostedt wrote:
> BTW, you have joined some of the discussions to these patches in the past.
> Do you subscribe to all the other mailing lists in the MAINTAINERS file too?

Nope.

I'm not even subscribed to lkml and now rarely join discussions at all.

Basically I look at lore every now and again using keyword searches
then download messages of some threads manually.

Re: [workflows]Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

On Wed, 2023-11-08 at 15:07 -0500, Steven Rostedt wrote:
> On Wed, 8 Nov 2023 14:34:47 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > I use to only do discussions on LKML and have myself Cc'd (or Cc myself in
> > the discussions), but then I couldn't manage the patches from my inbox. So
> > I set up the mailing list and added that to be Cc'd too in MAINTAINERS, so
> > that everything goes to the other mailing list as well. That would then keep
> > the patches in patchwork, but the discussions would still be visible to the
> > general audience on LKML.
> 
> BTW, you have joined some of the discussions to these patches in the past.
> Do you subscribe to all the other mailing lists in the MAINTAINERS file too?
> 
> If not, then you would not have been able to add your input to those
> discussions.

Third try, same content:
-----

Nope.

I'm not even subscribed to lkml and now rarely join discussions at all.

Basically I look at lore every now and again using keyword searches
then download messages of some threads manually.

Re: [workflows]Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

fourth try, this time above the fold, no idea why these
are showing up on ksummit as blank.

Nope.

I'm not even subscribed to lkml and now rarely join discussions at all.

Basically I look at lore every now and again using keyword searches
then download messages of some threads manually.


On Wed, 2023-11-08 at 12:36 -0800, Joe Perches wrote:
> On Wed, 2023-11-08 at 12:14 -0800, Joe Perches wrote:
> > On Wed, 2023-11-08 at 15:07 -0500, Steven Rostedt wrote:
> 
> <empty email?  evolution still sucks>
> 
> My sent email folder entry for this is:
> 
> On Wed, 2023-11-08 at 15:07 -0500, Steven Rostedt wrote:
> > BTW, you have joined some of the discussions to these patches in the past

Re: [workflows]Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Steven Rostedt]

On Wed, 08 Nov 2023 12:49:13 -0800
Joe Perches <joe@perches.com> wrote:

> fourth try, this time above the fold, no idea why these
> are showing up on ksummit as blank.
> 
> Nope.
> 
> I'm not even subscribed to lkml and now rarely join discussions at all.
> 
> Basically I look at lore every now and again using keyword searches
> then download messages of some threads manually.

I received the full message each time.

> 
> 
> On Wed, 2023-11-08 at 12:36 -0800, Joe Perches wrote:
> > On Wed, 2023-11-08 at 12:14 -0800, Joe Perches wrote:  
> > > On Wed, 2023-11-08 at 15:07 -0500, Steven Rostedt wrote:  
> > 
> > <empty email?  evolution still sucks>
> > 
> > My sent email folder entry for this is:
> > 
> > On Wed, 2023-11-08 at 15:07 -0500, Steven Rostedt wrote:  
> > > BTW, you have joined some of the discussions to these patches in the past  

I suggest to switch to claws-mail ;-)

-- Steve

RE: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Luck, Tony]

> Is there a way to use b4, lei, lore, etc. for responding to mail on a list one is
> not subscribed to?

I use:

$ b4 mbox {message-id-of-any-message-in-the-thread}
 ... b4 downloads thread in mbox format
$ mutt -f {that}.mbx
... find specific message and reply

-Tony
 

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[James Bottomley]

On Wed, 2023-11-08 at 20:04 +0000, Bird, Tim wrote:
> Is there a way to use b4, lei, lore, etc. for responding to mail on a
> list one is not subscribed to?

lore has a "reply" link which formats a reply correctly to be in-reply-
to the email (provided your local mail client supports this).

For something like gmail, which doesn't have a local client, you can do
it the old fashioned way: download the mbox of the email, import the
mbox into a folder and then reply to the message.

James

Re: [workflows]Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Konstantin Ryabitsev]

On Wed, Nov 08, 2023 at 03:56:06PM -0500, Steven Rostedt wrote:
> I received the full message each time.

I think Joe managed to hit a bug in mlmmj-1.4.0rc2 -- I had it enabled on
ksummit. That was actually the other reason I'd started this conversation, as
a way to test it on a large-ish list. ;)

I've rolled back ksummit to mlmmj-1.3.0 and this problem should go away while
I troubleshoot what happened.

-K

Re: [workflows]Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Steven Rostedt]

On Wed, 8 Nov 2023 16:04:30 -0500
Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

> On Wed, Nov 08, 2023 at 03:56:06PM -0500, Steven Rostedt wrote:
> > I received the full message each time.  
> 
> I think Joe managed to hit a bug in mlmmj-1.4.0rc2 -- I had it enabled on
> ksummit. That was actually the other reason I'd started this conversation, as
> a way to test it on a large-ish list. ;)

Doing testing the Linux kernel way (send it out to the users and see what breaks!)

-- Steve

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Johannes Berg]

On Wed, 2023-11-08 at 16:04 -0500, James Bottomley wrote:
> On Wed, 2023-11-08 at 20:04 +0000, Bird, Tim wrote:
> > Is there a way to use b4, lei, lore, etc. for responding to mail on a
> > list one is not subscribed to?
> 
> lore has a "reply" link which formats a reply correctly to be in-reply-
> to the email (provided your local mail client supports this).
> 

If it doesn't or you want the email to quote it, you can also click the
'raw' link, download the file and import it (it's a one-mail mbox), and
then reply. Kind of like the b4 suggestion, just without the tool.

Now if you want to actually reply from gmail, I don't know how to get
that in there, but I guess there's some way.

johannes

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Rob Herring]

On Wed, Nov 8, 2023 at 3:04 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Wed, 2023-11-08 at 20:04 +0000, Bird, Tim wrote:
> > Is there a way to use b4, lei, lore, etc. for responding to mail on a
> > list one is not subscribed to?
>
> lore has a "reply" link which formats a reply correctly to be in-reply-
> to the email (provided your local mail client supports this).

That just lists 3 options for replying. The first is the manual way to
do what Tony said with b4. The other 2 are use git-send-email or a
mailto: link, both which leave quoting up to the user.

b4 works great if you have the message-id already. Use lei if you want
a mbox of search results.

Rob

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Ian Kelling]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> On Mon, Nov 06, 2023 at 09:05:12AM -0800, Christoph Hellwig wrote:
>> How about restricting access to all lists for gmail addresses if gmail
>> is so
>> broken?
>
> Today it's gmail, tomorrow it's something else. Just a month ago all
> services
> using outlook.com were broken for days:
> https://learn.microsoft.com/en-us/answers/questions/1388775/outlook-com-servers-tells-server-busy-please-try-a
>
> All I want is to know is why someone wants to receive a copy of all
> patches
> via SMTP when much more effective mechanisms to achieve the same are
> available. If someone can provide a valid reason -- such as being a
> high-profile maintainer -- then of course I'll be happy to let them
> subscribe.
>
> -K

All kinds of services go down every day, smtp has good and bad, but I
see no reason to think it should be deprecated or anything. For example,
a good is that outgoing smtp is more resilient to ddos attacks than web
servers. Part of being a sysadmin is that things keep breaking tomorrow
and the next day, and we have to keep fixing them and it won't ever
stop. Yes, sometimes migrating people to very different software is the
fix, but I have experience running smtp at lists.gnu.org and from what
I've read so far, I think the problems you've described can be
effectively mitigated without restricting subscriptions nearly as much
as you propose in a reasonable effort. I'd be happy to provide a bit of
technical assistance.
-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Dan Carpenter]

On Wed, Nov 08, 2023 at 02:04:15PM -0500, Steven Rostedt wrote:
> 
> Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
> but I prefer the discussions to be done on LKML.
> 

I had no idea that how tracing worked...  I normally strip out mailing
lists from my patches if I think they're not necessary so I seldom CC
lkml.  In years past, there used to be a lot of complaining about CC'ing
too many people so I try to trim the CC list when I send patches.

Networking doesn't need to be CC'd about wireless patches.
Drm doesn't need to be CC'd about amd gpu driver patches.

And for bug reports, I only ever CC one lore mailing list.  (For zero
day bot stuff, the bot chooses the CC lists).

regards,
dan carpenter

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Laurent Pinchart]

On Thu, Nov 09, 2023 at 11:32:16AM +0300, Dan Carpenter wrote:
> On Wed, Nov 08, 2023 at 02:04:15PM -0500, Steven Rostedt wrote:
> > 
> > Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
> > but I prefer the discussions to be done on LKML.
> 
> I had no idea that how tracing worked...  I normally strip out mailing
> lists from my patches if I think they're not necessary so I seldom CC
> lkml.  In years past, there used to be a lot of complaining about CC'ing
> too many people so I try to trim the CC list when I send patches.

I do exactly the same and drop LKML from most of my patch submissions if
there are more "appropriate" (in the sense of more targetted) lists
reported by get_maintainer.pl.

> Networking doesn't need to be CC'd about wireless patches.
> Drm doesn't need to be CC'd about amd gpu driver patches.
> 
> And for bug reports, I only ever CC one lore mailing list.  (For zero
> day bot stuff, the bot chooses the CC lists).

-- 
Regards,

Laurent Pinchart

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Wed, Nov 08, 2023 at 02:34:47PM -0500, Steven Rostedt wrote:
> Joe Perches <joe@perches.com> wrote:

> > > Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
> > > but I prefer the discussions to be done on LKML.  

> > How would that work?  Especially with get_maintainer?

> The way it works now. Just Cc both lists. What's the problem with that?

So that's just CC the list and then both the patch and discussion end up
on both lists, which one you use is more of a personal thing with your
workflow.

> TRACING
> M:      Steven Rostedt <rostedt@goodmis.org>
> M:      Masami Hiramatsu <mhiramat@kernel.org>
> L:      linux-kernel@vger.kernel.org
> L:      linux-trace-kernel@vger.kernel.org
> S:      Maintained

That wouldn't be affected since it's an explicit thing in the entry for
the subsystem - it's not being picked up by the wildcard entry or by 
get_maintainers just automatically adding a CC to LKML to everything
even without it being explicitly listed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Laurent Pinchart]

On Thu, Nov 09, 2023 at 11:21:50AM +0000, Mark Brown wrote:
> On Wed, Nov 08, 2023 at 02:34:47PM -0500, Steven Rostedt wrote:
> > Joe Perches <joe@perches.com> wrote:
> 
> > > > Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
> > > > but I prefer the discussions to be done on LKML.  
> 
> > > How would that work?  Especially with get_maintainer?
> 
> > The way it works now. Just Cc both lists. What's the problem with that?
> 
> So that's just CC the list and then both the patch and discussion end up
> on both lists, which one you use is more of a personal thing with your
> workflow.
> 
> > TRACING
> > M:      Steven Rostedt <rostedt@goodmis.org>
> > M:      Masami Hiramatsu <mhiramat@kernel.org>
> > L:      linux-kernel@vger.kernel.org
> > L:      linux-trace-kernel@vger.kernel.org
> > S:      Maintained
> 
> That wouldn't be affected since it's an explicit thing in the entry for
> the subsystem - it's not being picked up by the wildcard entry or by 
> get_maintainers just automatically adding a CC to LKML to everything
> even without it being explicitly listed.

This would increase my trust in get_maintainer.pl, I would be less
likely to unconditionally remove LKML from the list it produces when I
send patches.

-- 
Regards,

Laurent Pinchart

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Naveen N Rao]

On Mon, Nov 06, 2023 at 10:11:48AM -0600, Eric W. Biederman wrote:
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
> 
> Has anyone come up with a good way to mirror the public inbox git
> repositories?
> 
> In the rare occasion when public inbox splits git repositories any
> script that just mirrors the git repository silent stops working.

If you're using l2md (which mirrors the repositories itself), or want to 
script this yourself, then you can check the manifest on lore to see if 
there are new repositories to be mirrored. I have a script that I run 
daily to check that. You can grab the manifest using:

  $ curl -s https://lore.kernel.org/manifest.js.gz | zcat | jq

Not sure if public-inbox-clone/public-inbox-fetch can instead be used 
with l2md.


- Naveen

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Steven Rostedt]

On Thu, 9 Nov 2023 11:32:16 +0300
Dan Carpenter <dan.carpenter@linaro.org> wrote:

> On Wed, Nov 08, 2023 at 02:04:15PM -0500, Steven Rostedt wrote:
> > 
> > Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
> > but I prefer the discussions to be done on LKML.
> >   
> 
> I had no idea that how tracing worked...  I normally strip out mailing
> lists from my patches if I think they're not necessary so I seldom CC
> lkml.  In years past, there used to be a lot of complaining about CC'ing
> too many people so I try to trim the CC list when I send patches.

You usually just send fixes, which is fine for not Cc'ing LKML.

Please do not strip linux-trace-kernel, though. As it keeps the responses
in patchwork.

> 
> Networking doesn't need to be CC'd about wireless patches.
> Drm doesn't need to be CC'd about amd gpu driver patches.
> 
> And for bug reports, I only ever CC one lore mailing list.  (For zero
> day bot stuff, the bot chooses the CC lists).

Which is fine.

I'm care more about new features, as tracing / scheduling / etc affect the
entire kernel. Changes in DRM usually only affect DRM. But a scheduling or
tracing change, could affect DRM, which is why I want to keep those patches
going to the generic mailing list.

-- Steve

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Laurent Pinchart]

On Thu, Nov 09, 2023 at 10:51:12AM -0500, Steven Rostedt wrote:
> On Thu, 9 Nov 2023 11:32:16 +0300 Dan Carpenter wrote:
> > On Wed, Nov 08, 2023 at 02:04:15PM -0500, Steven Rostedt wrote:
> > > 
> > > Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
> > > but I prefer the discussions to be done on LKML.
> > 
> > I had no idea that how tracing worked...  I normally strip out mailing
> > lists from my patches if I think they're not necessary so I seldom CC
> > lkml.  In years past, there used to be a lot of complaining about CC'ing
> > too many people so I try to trim the CC list when I send patches.
> 
> You usually just send fixes, which is fine for not Cc'ing LKML.
> 
> Please do not strip linux-trace-kernel, though. As it keeps the responses
> in patchwork.
> 
> > Networking doesn't need to be CC'd about wireless patches.
> > Drm doesn't need to be CC'd about amd gpu driver patches.
> > 
> > And for bug reports, I only ever CC one lore mailing list.  (For zero
> > day bot stuff, the bot chooses the CC lists).
> 
> Which is fine.
> 
> I'm care more about new features, as tracing / scheduling / etc affect the
> entire kernel. Changes in DRM usually only affect DRM. But a scheduling or
> tracing change, could affect DRM, which is why I want to keep those patches
> going to the generic mailing list.

They won't be seen by most DRM people though, as those people are most
likely not following LKML due to the amount of e-mails. I barely even
ever read lists these days due to the mail volume, even for the
subsystems I'm most involved with :-S

-- 
Regards,

Laurent Pinchart

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Steven Rostedt]

On Thu, 9 Nov 2023 18:08:34 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> They won't be seen by most DRM people though, as those people are most
> likely not following LKML due to the amount of e-mails. I barely even
> ever read lists these days due to the mail volume, even for the
> subsystems I'm most involved with :-S

True, but I do get random responses from people that I don't believe are
following the tracing list.

-- Steve

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Alex Elder]

On 11/9/23 3:27 AM, Laurent Pinchart wrote:
> On Thu, Nov 09, 2023 at 11:32:16AM +0300, Dan Carpenter wrote:
>> On Wed, Nov 08, 2023 at 02:04:15PM -0500, Steven Rostedt wrote:
>>>
>>> Right. For example, I use linux-trace-kernel@ to add patches to patchwork,
>>> but I prefer the discussions to be done on LKML.
>>
>> I had no idea that how tracing worked...  I normally strip out mailing
>> lists from my patches if I think they're not necessary so I seldom CC
>> lkml.  In years past, there used to be a lot of complaining about CC'ing
>> too many people so I try to trim the CC list when I send patches.

I used to do this too but at some point I was told I was leaving
someone or some list out.  It seemed get_maintainer.pl was returning
a smaller list of addressees than it once did, so I just started using
the list it produces.  It seems excessive though.

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).

					-Alex


> 
> I do exactly the same and drop LKML from most of my patch submissions if
> there are more "appropriate" (in the sense of more targetted) lists
> reported by get_maintainer.pl.
> 
>> Networking doesn't need to be CC'd about wireless patches.
>> Drm doesn't need to be CC'd about amd gpu driver patches.
>>
>> And for bug reports, I only ever CC one lore mailing list.  (For zero
>> day bot stuff, the bot chooses the CC lists).
> 

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Konstantin Ryabitsev]

On Thu, Nov 09, 2023 at 11:14:38AM -0600, Alex Elder 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.

-K

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

On Thu, 2023-11-09 at 12:25 -0500, Konstantin Ryabitsev wrote:
> On Thu, Nov 09, 2023 at 11:14:38AM -0600, Alex Elder 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 ?

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Konstantin Ryabitsev]

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

   And have special treatment for that entry.

I think this should gradually improve the linux-kernel mailing list to the
point where most people will start reading it again.

-K

[1] https://public-inbox.org/meta/20231107-skilled-cobra-of-swiftness-a6ff26@meerkat/T/#t

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Jason Gunthorpe]

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

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Linus Torvalds]

On Thu, 9 Nov 2023 at 15:16, Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> Is it possible you could do this on the backend and automatically
> route all patches send to any mailing list to this list?

I feel like this would make a "patches@lists.linux.dev" list add real value.

Developers might even be able to sign up to "virtual" lists, where
they get cc'd if a patch makes it to that list that has a file pattern
that matches their "I'm interested in these path patterns".

                 Linus

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Paolo Bonzini]

On 11/7/23 17:51, Konstantin Ryabitsev wrote:
>> What about_pulling_  all patches from public-inbox?  Right now the git repos
>> underhttps://lore.kernel.org/lkml/  do not catch everything, but it's close
>> enough.  There would be nohttps://lore.kernel.org/all/1.git/  and, even if
>> there were, there is no easy way to filter out non-Linux projects.
>
> Sorry, I'm not entirely sure what you're asking. You want to be able to
> automatically retrieve all patches but only if they are related to the kernel?

Just all patches, but bonus points if I can filter out those not 
delivered to any kernel mailing list (QEMU is the largest that is 
archived by lore).  I could do the filtering on my own backend, but I 
guess I'm not the only who'd use it.

I agree with Jason Gunthorpe, by far the best solution here would be a 
processor on the backend that subscribes to all kernel-related mailing 
list and imports the patches (and only the patches) to a public-inbox 
git archive.  This would make patches@lists.linux.dev just work, and 
would be awesome.

Paolo

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Jakub Kicinski]

On Thu, 9 Nov 2023 16:56:33 -0800 Linus Torvalds wrote:
> Developers might even be able to sign up to "virtual" lists, where
> they get cc'd if a patch makes it to that list that has a file pattern
> that matches their "I'm interested in these path patterns".

Yes. Please.

Could we possibly make that work via IMAP, inject the emails into
people's inboxes instead of via STMP? It may break local filtering
and would require that people give k.org passwords / API keys.
But we won't be running into the STMP rate limits any more.

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Konstantin Ryabitsev]

On Fri, Nov 10, 2023 at 09:04:46AM -0800, Jakub Kicinski wrote:
> On Thu, 9 Nov 2023 16:56:33 -0800 Linus Torvalds wrote:
> > Developers might even be able to sign up to "virtual" lists, where
> > they get cc'd if a patch makes it to that list that has a file pattern
> > that matches their "I'm interested in these path patterns".
> 
> Yes. Please.
> 
> Could we possibly make that work via IMAP, inject the emails into
> people's inboxes instead of via STMP? It may break local filtering
> and would require that people give k.org passwords / API keys.
> But we won't be running into the STMP rate limits any more.

Search-based mailboxes are coming Very Shortly Now (TM). It's mostly down to
the logistics of how to let people self-manage the queries (probably via git,
because this gives builtin history, rollback, etc).

You can already feed entire mailing lists into Gmail via POP3, so very shortly
you'll be able to define your own query (to run against /all/) and have that
available to you as a NNTP feed and a POP3 mailbox. I chose to start with POP3
because Gmail has a native mechanism to import that into your inbox. I've been
receiving the git list this way for the past month.

-K

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Rob Herring]

On Fri, Nov 10, 2023 at 11:04 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 9 Nov 2023 16:56:33 -0800 Linus Torvalds wrote:
> > Developers might even be able to sign up to "virtual" lists, where
> > they get cc'd if a patch makes it to that list that has a file pattern
> > that matches their "I'm interested in these path patterns".
>
> Yes. Please.
>
> Could we possibly make that work via IMAP, inject the emails into
> people's inboxes instead of via STMP? It may break local filtering
> and would require that people give k.org passwords / API keys.
> But we won't be running into the STMP rate limits any more.

I think that's already possible in lei. So it comes down to who runs
the IMAP server and where. If localhost works for you, then it should
just be a matter of configuring lei. Though I've not tried any of this
part of lei myself.

And I think there's folks that just want mail delivered to their inbox
with SMTP regardless of what lore/b4/lei can do.

Rob

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Jakub Kicinski]

On Fri, 10 Nov 2023 12:24:03 -0500 Konstantin Ryabitsev wrote:
> Search-based mailboxes are coming Very Shortly Now (TM).

🤩️

> It's mostly down to
> the logistics of how to let people self-manage the queries (probably via git,
> because this gives builtin history, rollback, etc).
> 
> You can already feed entire mailing lists into Gmail via POP3, so very shortly
> you'll be able to define your own query (to run against /all/) and have that
> available to you as a NNTP feed and a POP3 mailbox. I chose to start with POP3
> because Gmail has a native mechanism to import that into your inbox. I've been
> receiving the git list this way for the past month.

Ah, didn't think of POP import, should be perfect!

Re: [workflows]RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Jakub Kicinski]

On Fri, 10 Nov 2023 11:24:19 -0600 Rob Herring wrote:
> I think that's already possible in lei. So it comes down to who runs
> the IMAP server and where. If localhost works for you, then it should
> just be a matter of configuring lei. Though I've not tried any of this
> part of lei myself.

Nod, I've been trying to direct some newcomers towards lei for
subscribing to "manageable portions" of netdev. It's not hard,
but for folks from outside its a bit uncomfortable, and they
get stuck on details.

> And I think there's folks that just want mail delivered to their inbox
> with SMTP regardless of what lore/b4/lei can do.

I actually think that POP3 can do great things.

I know multiple people who don't even work on the kernel(!) but for
whatever reason get warm and fuzzy feelings from netdev getting
dumped into a folder in their gmail. A folder they never open.

If the SMTP gets "accidentally" unsubscribed every now and then
I'm pretty sure they'd happily switch to fetching a POP. 
IDK how representative the people I'm thinking of are, tho.

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Theodore Ts'o]

On Mon, Nov 06, 2023 at 12:41:18PM -0500, Konstantin Ryabitsev wrote:
> All I want is to know is why someone wants to receive a copy of all patches
> via SMTP when much more effective mechanisms to achieve the same are
> available. If someone can provide a valid reason -- such as being a
> high-profile maintainer -- then of course I'll be happy to let them subscribe.

It's not so much wanting to see "all patches", but rather wanting to
be able to see the discussion of a patch.  Perhaps if there is no
other vger list cc'ed on the message, there could be a reply-to: lkml
header set, to redirect messages someplace where it will be more
visible?

After all, we're talking about "THE REST", so these are patches which
don't have some kind of list associated with it, more or less by
definition.  And having discussions about a patch only show up on
patches@ list would be suboptimal.  If we were to address that,
perhaps that would make more people happy who are currently subscribed
to lkml?

And yes, I am subscribed to lkml, which I read^H^H^H^H skim with one
finger resting lightly on the 'D' key.  If there was a good summary
service (hey, maybe we could use one a LLM to provide a summary, with
lore link if people wanted more detail --- only half-kidding) then
that would be great, but I do like to keep a light touch on the pulse
of kernel development, and while LWN is a super-valuable, I'm looking
for the next level of detail...

					- Ted

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Joe Perches]

On Mon, 2023-11-06 at 10:33 -0500, Konstantin Ryabitsev wrote:
> For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> ("THE REST") to patches@lists.linux.dev instead.

Any agreement on this?

Re: RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org

[Greg KH]

On Tue, Nov 21, 2023 at 06:53:29AM -0800, Joe Perches wrote:
> On Mon, 2023-11-06 at 10:33 -0500, Konstantin Ryabitsev wrote:
> > For this reason, I propose switching the "F: *" entry in MAINTAINERS 
> > ("THE REST") to patches@lists.linux.dev instead.
> 
> Any agreement on this?

No disagreement from me!

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>