[PATCH 0/6] aiaiai: fixes for recent email configuration work

[Artem Bityutskiy]

On Tue, 2014-03-11 at 15:19 +0000, Keller, Jacob E wrote:
> On Tue, 2014-03-11 at 09:58 +0200, Artem Bityutskiy wrote:
> > On Mon, 2014-03-10 at 16:46 -0700, Jacob Keller wrote:
> > > This patch series includes several fixes for the recent changes to the email
> > > configuration. These mostly are silly typos and other things which finally got
> > > caught in testing.
> > > 
> > > It also includes one final patch that adds [debug] to the ini configuration
> > > file, for use with the old test_mode and preserve options, though I renamed
> > > them to be more easily understandable.
> > 
> > Looks good, thanks! Pushed all to "devel".
> > 
> 
> Thanks! :) I have now tested this patch series, I think maybe 1-2 more
> days of use in my environment just to ensure we've ironed out bugs would
> be good.
> 
> I also once again have an updated 3-patch series which carries the
> features I use.
> 
> There is one more in that list that I am hoping to redesign so that it
> works for aiaiai, which is the patch version detection.
> 
> It's not really valuable for gerrit model, since gerrit handles all of
> that for you essentially, so I don't know if use of the Change-Id: tag
> would work...
> 
> Subject is pretty finicky as well.. Generally on my list, people don't
> tend to rename the subject unless it's a new patch. Also people do tend
> to put v2 or rc2 or v2rc2 in their [...PATCH...] block. usually:
> 
> [PATCH net-next vXrcY M/N]
> 
> or
> 
> [net-next PATCH vXrcY M/N]
> 
> Any thoughts on how to handle this? I am going to send this patch for
> review again so that you can have a look at how this could best be
> handled...
> 
> Maybe this feature could be pulled into the main aiaiai-test-patchset,
> and be used only incase the feature fails to apply?

Architecturally, but common sense tells me this.

1. Different groups have different preferences, and it is probably
difficult to have a single script which suite every group.
2. Therefore, peculiar things like this should be separate somehow.

So generally, if you could invent something which sits between lda and
email-test-patch-set and handles a peculiarities of the group, that
would be a clean approach:

lda -> handle-xyz-kinks -> aiaia-email-test-patch-set

:-)

Now, the 'handle-xyz-kinks' may need help from the lower-level scripts.
If was something generally useful, that would be perfect. I'd probably
think about implementing this the following way:

1. handle-xyz-kinks adds various extra special headers to the mbox. The
tags try to be generally useful.

2. aiaiai-email-test-patch-set interprets the extra headers.

3. if needed, aiaiai-test-patch-set gets new command-line options, and
aiaiai-email-test-patch-set uses those options to do what the extra
headers instruct.

How does this sound?

-- 
Best Regards,
Artem Bityutskiy