Re: [Summit topic] Improving reviewer quality of life (patchwork, subsystem lists?, etc)

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Thu, Oct 21, 2021 at 01:57:11PM +0200, Johannes Schindelin wrote:
>  2. Dscho said he’s not able to follow everything on the mailing list
> 
>     1. if you have just one patch you send, reply-all works okay
> 
>     2. mailing list works reasonably well if you’re someone like Junio, working
>        on it full time, has good mail filters, keeps up to date with everything
> 
>     3. If you’re in-between, does not work well

This is a problem that's not actually unique to mailing lists. If you have any
project that is popular enough, at some point it reaches critical mass where
developer/user feedback becomes too much for anyone to keep up. Github
projects aren't immune to this either, but they do have a benefit of providing
an easy interface for someone to apply categorization to issues/discussions.

One of the efforts currently under way at public-inbox is the "lei" tool that
should allow similar workflows for mailing-list based interactions. At some
point we will be able to provide both topical and search-based subscriptions
to subsets of the mailing list traffic that you're interested in. Search-based
subscriptions will allow you to monitor the list for discussions relevant to
your interest (e.g. patches touching functions/files/keywords that you are
working on). Topical subscriptions are a bit more complicated and would
require someone to actively categorize mailing list discussions by keywords
(e.g. bugs, suggestions, security), which would allow others to monitor just
those aspects of mailing list discussion. The latter requires someone's active
involvement and dedication from the project side, not unlike for categorizing
issues reported at github or any other issue tracker.

If you're curious, you can see my presentation to Linux Plumbers last month,
which is here:
youtube: https://www.youtube.com/watch?v=mF10hgVIx9o&t=1490s
slides: https://linuxplumbersconf.org/event/11/contributions/983/attachments/759/1421/Doing%20more%20with%20lore%20and%20b4.pdf

>  4. bmc: I want some way to track patches
> 
>     1. What have I reviewed before and what have I not reviewed since last
>        time?
> 
>     2. Emily: most of this exists in patchwork. Our intern Raxel Gutierrez did
>        work on that this summer. Alas, that doesn’t show up on
>        patchwork.kernel.org because it’s using patchwork 2.x and the features
>        are in 3.x

3.x is a bit new still, but chances are we'll be running it in a couple of
months. Unfortunately, our previous experiences with major patchwork upgrades
have been a bit thorny, so I'm trying to approach this carefully in order not
to impact other projects relying on it. (Not a dig at patchwork folks, just an
observation.)

>     7.  jrnieder: there’s a bugzilla instance at bugzilla.kernel.org, which
>         might satisfy CB’s criterion
> 
>     8.  bmc: I want to have whatever we use send out to the list. That would
>         avoid conversations going on without people in the mailing list centric
>         workflow being aware of it. If we are all using a GitHub/GitLab based
>         workflow then that’s not required

Bugzilla's mail integration is fairly good and list-friendly. We have several
projects that largely interact with their bugzilla via mailing lists
(two-way). Note, that someone still has to do things like closing and
recategorizing bugs through the website.

Note, that the initial bug report must come in through the bugzilla web
interface. There's a way to create bugs via incoming mail, but it works very
poorly.

>     13. Junio: Not really. The extra tracking conversations are not as
>         important to me. I think it’s a feature that if someone requests a
>         feature and nothing happens for a while that it no longer produces
>         overhead for people is a useful feature. That kind of old filtering
>         feature is sometimes valuable.

I find that if there's no mailing list integration, then bugzilla generally
rots after the initial person getting the bug reports moves on. Then bugs
reported via bugzilla just sit there without anyone paying attention. At least
when bug reports get sent to the list, the ensuing discussions get reflected
in both the list archives and in bugzilla.

>     16. I’m also happy to work with kernel.org admins to get this set up for us
>         if that’s what we want

Consider this part done. :)

-K