Message-ID: <20230701163836.173b0c84@kernel.org>
Date: Sat, 1 Jul 2023 16:38:36 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Toke Høiland-Jørgensen <toke@...nel.org>
Cc: netdev@...r.kernel.org
Subject: Re: [ANN] pw-bot now recognizes all MAINTAINTERS

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

Powered by blists - more mailing lists