[PATCH] Implement list filtering

[Veronika Kabatova]

----- Original Message -----
> From: "Stephen Finucane" <stephen at that.guru>
> To: "Daniel Axtens" <dja at axtens.net>, "Don Zickus" <dzickus at redhat.com>
> Cc: patchwork at lists.ozlabs.org
> Sent: Wednesday, January 31, 2018 11:25:03 AM
> Subject: Re: [PATCH] Implement list filtering
> 
> On Wed, 2018-01-31 at 13:25 +1100, Daniel Axtens wrote:
> > Don Zickus <dzickus at redhat.com> writes:
> > 
> > > On Mon, Jan 29, 2018 at 11:36:36PM +1100, Daniel Axtens wrote:
> > > > Hi Don,
> > > > 
> > > > > > I suppose to put a finer point on it - what is your usecase here?
> > > > > > What
> > > > > > are you trying to achieve, and can we help you do that in a way
> > > > > > that
> > > > > > requires smaller changes to Patchwork, and is less fragile? (For
> > > > > > example
> > > > > > this is going to break if someone mis-spells the keyword you're
> > > > > > looking
> > > > > > for in the subject_match.)
> > > > > 
> > > > > So here is our use case.  Internally at Red Hat we use one mailing
> > > > > list to
> > > > > post all of our kernel patches.  However, being a distro company,
> > > > > patches
> > > > > can be applied to either RHEL-6,7,X.  For the last 15 years we have
> > > > > always
> > > > > used the method:
> > > > > 
> > > > > [RHEL-7 PATCH] instead of [PATCH].
> > > > 
> > > > Ah yes. I work for Canonical (although I do Patchwork in a private
> > > > capacity only) and our kernel team does something very similar.
> > > > 
> > > > > The project inside the []s has been what we filter through our regex.
> > > > > Is it
> > > > > prone to human typos?  Yes.  Most folks have stuck this in the
> > > > > .git/config
> > > > > subjectprefix option.  That limited the typos. It isn't perfect.
> > > > > 
> > > > > We have been using a hacked up PatchWork1 for the last 7 or so years.
> > > > > This
> > > > > is one of those features we need (or something to solve our problem)
> > > > > if we
> > > > > want to migrate to a PatchWork2 instance.
> > > > > 
> > > > > I hope that adds a little bit of context on our thinking.  Thoughts?
> > > > 
> > > > That's a compelling use-case and I'm happy to look at supporting it. I
> > > > will review the patch more closely in the coming days.
> > > 
> > > Thanks for your understanding and support!
> > > 
> > > Again, we know the solution has its 'human' limitations. :-) We just
> > > never
> > > came up with a better idea. So any ideas there are welcomed too! :-)
> > 
> > [I will eventually get around to reviewing the patch proper, this is just
> > spitballing.]
> > 
> > One option that came to me last night would be to do this filtering
> > before the emails are injested into patchwork. To elaborate:
> > 
> > I assume you're injesting mail using something like the setup described
> > at
> > http://patchwork.readthedocs.io/en/master/deployment/installation/#mail-transfer-agent-mta
> > that is:
> > 
> > $ sudo cat << EOF > /etc/aliases
> > patchwork: "|/opt/patchwork/patchwork/bin/parsemail.sh"
> > EOF
> > 
> > So what you could do is pass the email to something like procmail first,
> > let that filter the messages on your regexes, and then pass the filtered
> > mail to parsemail.sh, using an explicit list-id parameter to deliver it
> > to the right project.
> 

We are using the getmail method and previously did something similar
but weren't very happy with that solution since it was harder to
manage and required direct access to the machine.

> What would be the advantage of this though? Far as I can tell, there is
> a clear pattern here for mailing lists that are shared by multiple
> projects, namely, the use of a specific subject tag. I've seen this
> pattern in use on other development mailing lists (openstack-dev jumps
> to mind).
> 
> > This doesn't involve patchwork at all, which is both a strength (it's
> > simple for me) and a weakness (it's complex for you and involves
> > spreading config across 2 places).
> 
> To be honest, given how simple and generic this patch is, I'd prefer to
> keep the logic within Patchwork. It would require much less work on an
> administrators end over all (seeing as they'll have to configure
> procmail too), and be far more transparent to end users.
> 

I agree. Our goal is to have Patchwork as a service (container or VM)
managed by DevOps or similar team. This solution would make it uselessly
hard to for example add and edit projects -- instead of having our
Patchwork admin user click a few times, we would need to contact those
people and explain to them how to change the configuration with every
change we need. And as Stephen said, it's really not a straightforward
and transparent solution.

Veronika

> Thoughts?
> 
> Stephen
> _______________________________________________
> Patchwork mailing list
> Patchwork at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork
>