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.
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. Thoughts? Stephen _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
