Using merge_config.sh

[Dave Jones]

On Wed, Feb 01, 2012 at 03:32:26PM -0500, Josh Boyer wrote:
 
 > > So I would be torn and lean away from it until the speed improves.  I know
 > > if this makes it to RHEL people would complain and it would get ripped out
 > > in favor of the old way.
 > 
 > If we're going on pure speed then sure.  There's no reason to replace
 > what is working today with something that is much slower.  What I'm more
 > interested in though, is either:

Given this is a common case (I couldn't guess how many 'make prep's I do
each day, but it's easily in double figures), I don't think that kind of
slowdown is going to be acceptable for us at all.

 > 1) Does the additional verification from merge_config.sh prove useful
 > enough to warrant a slowdown?  I can see it being useful to make sure we
 > don't screw something up on a rebase, etc.
 > 
 > 2) Can merge.pl be adapted to produce similar output without making it
 > much slower?
 > 
 > If I have to go with 2, I'll be replacing merge.pl with merge.py because
 > I don't speak perl. ;)
 > 
 > Alternatively, we could make it an option to use the upstream stuff so
 > that if we're doing a rebase or just want to see what the hell is going
 > on, it's a trivial toggle of something to switch.  I don't think the
 > code for that would be all that ugly at all.

Or perhaps make an additional tool perhaps just to sanity check things ?
(Given it's only really something that we care about when we pull in
 a new upstream snapshot for the most part)

My first thought when I read the output was 'yeah, we know this is over-riding that'.
That's going to get tedious to read every make prep, and I think any real
problems would get lost in the noise. Perhaps we'd need a way to annotate
overrides in our template files so they could be ignored when we had reviewed
them and made sure they were ok.

	Dave