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
_______________________________________________
kernel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel
