Message-ID: <87fs65ceuw.fsf@toke.dk>
Date: Mon, 03 Jul 2023 15:19:03 +0200
From: Toke Høiland-Jørgensen <toke@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org
Subject: Re: [ANN] pw-bot now recognizes all MAINTAINTERS

Jakub Kicinski <kuba@...nel.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

Powered by blists - more mailing lists