Re: Using merge_config.sh

2012-02-03 Thread 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
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Using merge_config.sh

2012-02-02 Thread 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

___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Using merge_config.sh

2012-02-01 Thread Don Zickus 
On Wed, Feb 01, 2012 at 01:33:41PM -0500, Josh Boyer wrote:
 Hi All,
 
 We've been using merge.pl to merge Fedora's config file fragments for as
 long as I can remember.  However, in the interest of using what's
 upstream, I took a look at the newly added merge_config.sh script and
 what it would take to use that instead.

I remember looking at this last week and thinking the same thing.  I
remember hacking on merge.pl years ago and optimizing to run really fast.
Even today there are RH folks who complain it still runs slow.

I thought the same as you, why not start using the upstream approach and
have one less thing to maintain/worry about in the fedora spec file.

But the major plus with using perl was you could cache the file in memory
and it only had to be read once.  With the script, files are read multiple
times which add to the delay.

There is really no way around it unless upstream converts to perl or
python or even 'c'.

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.

My two cents.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Using merge_config.sh

2012-02-01 Thread Josh Boyer 
On Wed, Feb 01, 2012 at 03:24:23PM -0500, Don Zickus wrote:
 On Wed, Feb 01, 2012 at 01:33:41PM -0500, Josh Boyer wrote:
  Hi All,
  
  We've been using merge.pl to merge Fedora's config file fragments for as
  long as I can remember.  However, in the interest of using what's
  upstream, I took a look at the newly added merge_config.sh script and
  what it would take to use that instead.
 
 I remember looking at this last week and thinking the same thing.  I
 remember hacking on merge.pl years ago and optimizing to run really fast.
 Even today there are RH folks who complain it still runs slow.

Yes, merge.pl is rather fast.

I did happen to time _just_ the make -f Makefile.{config,merge} portion
in the %prep section.  merge.pl takes 2 seconds.  merge_config.sh+patch
takes 2m.

 I thought the same as you, why not start using the upstream approach and
 have one less thing to maintain/worry about in the fedora spec file.
 
 But the major plus with using perl was you could cache the file in memory
 and it only had to be read once.  With the script, files are read multiple
 times which add to the delay.
 
 There is really no way around it unless upstream converts to perl or
 python or even 'c'.
 
 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:

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.

josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel