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

[Keller, Jacob E]

On Thu, 2014-03-13 at 10:16 +0200, Artem Bityutskiy wrote:
> 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?
> 

I agree, this is probably the best approach, as we can more easily
modify only those parts that have kinks.

I like the idea of using more custom mailbox headers.

Thanks,
Jake