* [ANN] pw-bot now recognizes all MAINTAINTERS
@ 2023-06-30 15:58 Jakub Kicinski
2023-07-01 14:04 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 4+ messages in thread
From: Jakub Kicinski @ 2023-06-30 15:58 UTC (permalink / raw)
To: netdev@vger.kernel.org, netdev-driver-reviewers@vger.kernel.org
Hi!
tl;dr pw-bot now cross references the files touched by a *series* with
MAINTAINERS and gives access to all patchwork states to people listed
as maintainers (email addrs must match!)
During the last merge window we introduced a new pw-bot which acts on
simple commands included in the emails to set the patchwork state
appropriately:
https://lore.kernel.org/all/20230508092327.2619196f@kernel.org/
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#updating-patch-status
This is useful in multiple ways, the two main ones are that (1) general
maintainers have to do less clicking in patchwork, and that (2) we have
a log of state changes, which should help answer the question "why
is my patch in state X":
https://patchwork.hopto.org/pw-bot.html
The bot acts automatically on emails from the kbuild bot. Author of
the series can also discard it from patchwork (but not bring it back).
Apart from that maintainers and select reviewers had access rights
to the commands. Now the bot has been extended to understand who the
maintainers are on series-by-series basis, by consulting MAINTAINERS.
Anyone who is listed as a maintainer of any files touched by the series
should be able to change the state of the series, both discarding it
(e.g. changes-requested) and bringing it back (new, under-review).
The main caveat is that the command must be sent from the email listed
in MAINTAINERS. I've started hacking on aliasing emails but I don't
want to invest too much time unless it's actually a problem, so please
LMK if this limitation is stopping anyone from using the bot.
The names of the states and their shortcuts are in the source code:
https://github.com/kuba-moo/nipa/blob/master/mailbot.py#L46
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ANN] pw-bot now recognizes all MAINTAINTERS
2023-06-30 15:58 [ANN] pw-bot now recognizes all MAINTAINTERS Jakub Kicinski
@ 2023-07-01 14:04 ` Toke Høiland-Jørgensen
2023-07-01 23:38 ` Jakub Kicinski
0 siblings, 1 reply; 4+ messages in thread
From: Toke Høiland-Jørgensen @ 2023-07-01 14:04 UTC (permalink / raw)
To: Jakub Kicinski, netdev@vger.kernel.org,
netdev-driver-reviewers@vger.kernel.org
Jakub Kicinski <kuba@kernel.org> writes:
> Hi!
>
> tl;dr pw-bot now cross references the files touched by a *series* with
> MAINTAINERS and gives access to all patchwork states to people listed
> as maintainers (email addrs must match!)
>
>
> During the last merge window we introduced a new pw-bot which acts on
> simple commands included in the emails to set the patchwork state
> appropriately:
>
> https://lore.kernel.org/all/20230508092327.2619196f@kernel.org/
> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#updating-patch-status
>
> This is useful in multiple ways, the two main ones are that (1) general
> maintainers have to do less clicking in patchwork, and that (2) we have
> a log of state changes, which should help answer the question "why
> is my patch in state X":
>
> https://patchwork.hopto.org/pw-bot.html
>
> The bot acts automatically on emails from the kbuild bot. Author of
> the series can also discard it from patchwork (but not bring it back).
> Apart from that maintainers and select reviewers had access rights
> to the commands. Now the bot has been extended to understand who the
> maintainers are on series-by-series basis, by consulting MAINTAINERS.
> Anyone who is listed as a maintainer of any files touched by the series
> should be able to change the state of the series, both discarding it
> (e.g. changes-requested) and bringing it back (new, under-review).
>
> The main caveat is that the command must be sent from the email listed
> in MAINTAINERS. I've started hacking on aliasing emails but I don't
> want to invest too much time unless it's actually a problem, so please
> LMK if this limitation is stopping anyone from using the bot.
Very cool! Follow-up question: are you expecting subsystem maintainers
to make use of this, or can we continue to rely on your benevolent
curation of patchwork states and only consider this an optional add-on? :)
Also, this only applies to the netdevbpf patchwork instance, right?
-Toke
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ANN] pw-bot now recognizes all MAINTAINTERS
2023-07-01 14:04 ` Toke Høiland-Jørgensen
@ 2023-07-01 23:38 ` Jakub Kicinski
2023-07-03 13:19 ` Toke Høiland-Jørgensen
0 siblings, 1 reply; 4+ messages in thread
From: Jakub Kicinski @ 2023-07-01 23:38 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: netdev
On Sat, 01 Jul 2023 16:04:50 +0200 Toke Høiland-Jørgensen wrote:
> > tl;dr pw-bot now cross references the files touched by a *series* with
> > MAINTAINERS and gives access to all patchwork states to people listed
> > as maintainers (email addrs must match!)
> >
> >
> > During the last merge window we introduced a new pw-bot which acts on
> > simple commands included in the emails to set the patchwork state
> > appropriately:
> >
> > https://lore.kernel.org/all/20230508092327.2619196f@kernel.org/
> > https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#updating-patch-status
> >
> > This is useful in multiple ways, the two main ones are that (1) general
> > maintainers have to do less clicking in patchwork, and that (2) we have
> > a log of state changes, which should help answer the question "why
> > is my patch in state X":
> >
> > https://patchwork.hopto.org/pw-bot.html
> >
> > The bot acts automatically on emails from the kbuild bot. Author of
> > the series can also discard it from patchwork (but not bring it back).
> > Apart from that maintainers and select reviewers had access rights
> > to the commands. Now the bot has been extended to understand who the
> > maintainers are on series-by-series basis, by consulting MAINTAINERS.
> > Anyone who is listed as a maintainer of any files touched by the series
> > should be able to change the state of the series, both discarding it
> > (e.g. changes-requested) and bringing it back (new, under-review).
> >
> > The main caveat is that the command must be sent from the email listed
> > in MAINTAINERS. I've started hacking on aliasing emails but I don't
> > want to invest too much time unless it's actually a problem, so please
> > LMK if this limitation is stopping anyone from using the bot.
>
> Very cool! Follow-up question: are you expecting subsystem maintainers
> to make use of this, or can we continue to rely on your benevolent
> curation of patchwork states and only consider this an optional add-on? :)
On a scale of 1 to 10 where 1 is forbidden and 10 is required I'd give
it 7. I don't know of any such systems, so it's a bit of an experiment.
But if nobody is using it, it won't be an experiment.
The experience of the select reviewers using it so far has been
pretty flawless from my perspective (I mean - there were technical
glitches but no disagreements, misunderstandings or misuses).
There may be an experience gap from the reviewer perspective.
Reviewers traditionally don't use patchwork that much (AFAIU),
so adding actions to update patchwork state may not come naturally.
Maybe a better way of looking at it is - if you're reviewing a patch
that you don't want to be applied, just throw in the command, as if
you were telling the maintainer that you don't think the patch is ready?
> Also, this only applies to the netdevbpf patchwork instance, right?
The daemon reads a single lore archive and targets a single patchwork
instance. Ours is set up for netdev and netdevbpf, yes. But the code
isn't in any way netdev specific and consumes almost no resources..
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ANN] pw-bot now recognizes all MAINTAINTERS
2023-07-01 23:38 ` Jakub Kicinski
@ 2023-07-03 13:19 ` Toke Høiland-Jørgensen
0 siblings, 0 replies; 4+ messages in thread
From: Toke Høiland-Jørgensen @ 2023-07-03 13:19 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
Jakub Kicinski <kuba@kernel.org> writes:
> On Sat, 01 Jul 2023 16:04:50 +0200 Toke Høiland-Jørgensen wrote:
>> > tl;dr pw-bot now cross references the files touched by a *series* with
>> > MAINTAINERS and gives access to all patchwork states to people listed
>> > as maintainers (email addrs must match!)
>> >
>> >
>> > During the last merge window we introduced a new pw-bot which acts on
>> > simple commands included in the emails to set the patchwork state
>> > appropriately:
>> >
>> > https://lore.kernel.org/all/20230508092327.2619196f@kernel.org/
>> > https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#updating-patch-status
>> >
>> > This is useful in multiple ways, the two main ones are that (1) general
>> > maintainers have to do less clicking in patchwork, and that (2) we have
>> > a log of state changes, which should help answer the question "why
>> > is my patch in state X":
>> >
>> > https://patchwork.hopto.org/pw-bot.html
>> >
>> > The bot acts automatically on emails from the kbuild bot. Author of
>> > the series can also discard it from patchwork (but not bring it back).
>> > Apart from that maintainers and select reviewers had access rights
>> > to the commands. Now the bot has been extended to understand who the
>> > maintainers are on series-by-series basis, by consulting MAINTAINERS.
>> > Anyone who is listed as a maintainer of any files touched by the series
>> > should be able to change the state of the series, both discarding it
>> > (e.g. changes-requested) and bringing it back (new, under-review).
>> >
>> > The main caveat is that the command must be sent from the email listed
>> > in MAINTAINERS. I've started hacking on aliasing emails but I don't
>> > want to invest too much time unless it's actually a problem, so please
>> > LMK if this limitation is stopping anyone from using the bot.
>>
>> Very cool! Follow-up question: are you expecting subsystem maintainers
>> to make use of this, or can we continue to rely on your benevolent
>> curation of patchwork states and only consider this an optional add-on? :)
>
> On a scale of 1 to 10 where 1 is forbidden and 10 is required I'd give
> it 7. I don't know of any such systems, so it's a bit of an experiment.
> But if nobody is using it, it won't be an experiment.
>
> The experience of the select reviewers using it so far has been
> pretty flawless from my perspective (I mean - there were technical
> glitches but no disagreements, misunderstandings or misuses).
>
> There may be an experience gap from the reviewer perspective.
> Reviewers traditionally don't use patchwork that much (AFAIU),
> so adding actions to update patchwork state may not come naturally.
> Maybe a better way of looking at it is - if you're reviewing a patch
> that you don't want to be applied, just throw in the command, as if
> you were telling the maintainer that you don't think the patch is ready?
Right, gotcha! Will try my best to remember to do this (not that there
are that many patches where it's relevant for me to do so, but anyhow) :)
>> Also, this only applies to the netdevbpf patchwork instance, right?
>
> The daemon reads a single lore archive and targets a single patchwork
> instance. Ours is set up for netdev and netdevbpf, yes. But the code
> isn't in any way netdev specific and consumes almost no resources..
OK. Was thinking of the wireless patchwork+list, specifically. Guess
I'll poke Johannes and Kalle after the holidays...
-Toke
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-07-03 13:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-30 15:58 [ANN] pw-bot now recognizes all MAINTAINTERS Jakub Kicinski
2023-07-01 14:04 ` Toke Høiland-Jørgensen
2023-07-01 23:38 ` Jakub Kicinski
2023-07-03 13:19 ` Toke Høiland-Jørgensen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).