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

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Oct 21, 2021, 13:41 UTC
Message-ID: <20211021134105.ziqmcknnpdsg6cvc@meerkat.local>
In-Reply-To: <nycvar.QRO.7.76.6.2110211150460.56@tvgsbejvaqbjf.bet>

On Thu, Oct 21, 2021 at 01:57:11PM +0200, Johannes Schindelin wrote:

Show 8 quoted lines

>  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

Show 9 quoted lines

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

Show 7 quoted lines

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

Show 5 quoted lines

>     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