Using merge_config.sh

[Josh Boyer]

On Thu, Feb 02, 2012 at 08:16:40PM -0500, Dave Jones wrote:
> 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.

Yeah.  I got tired of waiting for it to complete while I was testing it,
so waiting for it daily might drive me nuts.

>  > 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.

Right.  The output I attached wasn't the best example, since the way I
have it coded to make it performant at all was to keep it from doing
'make oldconfig' for us.  If you let it do that, it does some additional
verification to make sure the options you set are actually present in
the final config, and it tells you if they aren't (or are different).
That part is useful, but I agree it might be done better in a seperate
tool.

I'll look at that soon.

josh