[RFC] filter function for submaintainers

[RFC] filter function for submaintainers

[Uwe Kleine-König]

Hello,

at Pengutronix we think about using patchwork for the imx maintenance of
the kernel. (That is all related to arch/arm/{mach-{imx,mx*},plat-mxc}.)

The problem (admittedly only from a quick glance at
patchwork.ozlabs.org) I see is that it's not possible to reliably filter
patches by directory name. (Or maybe I'm just to stupid to find the
right knob, I tried searching for "drivers/net/ehea" in the netdev
project, got a few hits, but e.g.
http://patchwork.ozlabs.org/patch/89837/ wasn't listed. My guess is that
the search only checks subject and commit log?)

For us I think this is a crucial function, because the imx patches are
usually sent to the linux-arm-kernel mailing list where most patches
don't touch the files we are responsible for.

The obvious way to work around that problem is to set up a private
instance of patchwork and use procmail filtering to only feed it with
the "interesting" patches. Alternatively we have to convince enough
people to use the same instance such that only a few patches are left
without a responsible person. These few could then be
marked/deleted/whatever by many people and won't be a big problem.

Actually I would prefer a public instance that collects all patches from
the linux-arm-kernel mailing list. So it would be really great to have
such a filter.

Do you consider that a good feature? Would it be possible to get that
online on patchwork.ozlabs.org and let that instance host a
linux-arm-kernel project? (Assuming someone is willing to implement it
first.) I have to talk to my boss first and check with him if I can
invest some time to implement that, but if someone else volunteers to do
it, that would be fine for me, too.

(I wrote "we" through the mail, actually I'm not the maintainer of imx,
I just did one round of collecting patches recently and I'm already
annoyed.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[RFC] filter function for submaintainers

[Jeremy Kerr]

Hi Uwe,

> The problem (admittedly only from a quick glance at
> patchwork.ozlabs.org) I see is that it's not possible to reliably filter
> patches by directory name. (Or maybe I'm just to stupid to find the
> right knob, I tried searching for "drivers/net/ehea" in the netdev
> project, got a few hits, but e.g.
> http://patchwork.ozlabs.org/patch/89837/ wasn't listed. My guess is that
> the search only checks subject and commit log?)

At present, the search only covers the patch subject.

> For us I think this is a crucial function, because the imx patches are
> usually sent to the linux-arm-kernel mailing list where most patches
> don't touch the files we are responsible for.

It sounds like a separate linux-imx patchwork instance would suit better
- this would mean you don't have to constantly apply filters to get the
patches that you're interested in.

I'm very happy to set up a patchwork instance on ozlabs.org for you; but
(as you've mentioned) we'd need to filter-out the imx patches from the
rest of the l-a-k content that you're not interested in tracking.

Most projects (eg linux-davinci, linux-omap) do this by using a separate
mailing list; I assume you'd rather keep your patches on the main ARM
list, correct?

Since this is a one-off, I think an external program to filter relevant
patches from l-a-k would be best. This would check the diffstat for
interesting paths, then conditionally feed the patch to the patchwork
parser.

Would this suit? Are you OK with including patches that are not
necessarily imx-specific, but touch imx-related code (eg,
architecture-wide code cleanups)?

Cheers,


Jeremy

[RFC] filter function for submaintainers

[Uwe Kleine-König]

Hello Jeremy,

On Thu, Apr 07, 2011 at 10:00:06AM +0800, Jeremy Kerr wrote:
> > The problem (admittedly only from a quick glance at
> > patchwork.ozlabs.org) I see is that it's not possible to reliably filter
> > patches by directory name. (Or maybe I'm just to stupid to find the
> > right knob, I tried searching for "drivers/net/ehea" in the netdev
> > project, got a few hits, but e.g.
> > http://patchwork.ozlabs.org/patch/89837/ wasn't listed. My guess is that
> > the search only checks subject and commit log?)
> 
> At present, the search only covers the patch subject.
> 
> > For us I think this is a crucial function, because the imx patches are
> > usually sent to the linux-arm-kernel mailing list where most patches
> > don't touch the files we are responsible for.
> 
> It sounds like a separate linux-imx patchwork instance would suit better
> - this would mean you don't have to constantly apply filters to get the
> patches that you're interested in.
"constantly apply filters" could be a "view" saved in the settings.
Something like:

	<a href="...">all incoming patches</a>
	<a href="...">imx patches<a/>

on project/$project/list/, and in the settings something like

	views:
		- all
		- imx
			                    ,------------------------------------.
			files/dirs touched: | arch/arm/{plat-mxc,mach-{imx,mx*}} |
			                    `------------------------------------'
			maybe some more criterias?

	default view: O all , X imx

together with a "New view" button.

> I'm very happy to set up a patchwork instance on ozlabs.org for you; but
> (as you've mentioned) we'd need to filter-out the imx patches from the
> rest of the l-a-k content that you're not interested in tracking.
> 
> Most projects (eg linux-davinci, linux-omap) do this by using a separate
> mailing list; I assume you'd rather keep your patches on the main ARM
> list, correct?
*I* don't consider it sensible to have a seperate mailing list, I'd
expect Sascha to agree. And in fact we already have such a list, because
a mail sent to Sascha's email address listed in the MAINTAINERS file
ends in the mailboxes of all developers at Pengutronix.

> Since this is a one-off, I think an external program to filter relevant
> patches from l-a-k would be best. This would check the diffstat for
> interesting paths, then conditionally feed the patch to the patchwork
> parser.
> 
> Would this suit? Are you OK with including patches that are not
> necessarily imx-specific, but touch imx-related code (eg,
> architecture-wide code cleanups)?
That would be great. And yes, I'd want to include all patches that touch
arch/arm/{plat-mxc,mach-{imx,mx*}}.

But please don't invest too much effort here. We didn't use patchwork up
to know. I expect it will ease our workflow but as we're not 100% sure,
I'd have a bad conscience if you had a big effort and we say in 2 months
it doesn't help us much.
So if that's easier for you, just egreping the body instead of the
diffstat is enough (and probably produces an equivalent result most of
the time).

Something like the following (assuming you use procmail) should be fine:

	:0 B
	* arch/arm/(plat-mxc|mach-(imx|mx[^/]*))/
	| don't know you action line

should be fine.

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |