----- Original Message ----- > From: "Stephen Finucane" <step...@that.guru> > To: "Daniel Axtens" <d...@axtens.net>, "Don Zickus" <dzic...@redhat.com> > Cc: patchwork@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 <dzic...@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@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/patchwork > _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork