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 kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
