performance testing rawhide.

[Eric Sandeen]

On 09/23/2010 11:48 PM, Jarod Wilson wrote:
> On Sep 24, 2010, at 12:34 AM, Kyle McMartin <kyle at mcmartin.ca>
> wrote:
> 
>> On Thu, Sep 23, 2010 at 11:24:54PM -0400, Dave Jones wrote:
>>> I dunno. at this point, I'm torn over whether to keep pushing in
>>> this direction. The spec is already getting ugly with all those
>>> damn %defines.
>>> 
>> 
>> If everyone is going to end up running -nodebug, and we're going to
>> keep asking them to reproduce on the debug variant, what's the
>> point of not just continuing as we're doing now?
>> 
>> Having people flip flop between -nodebug and default between
>> release and not is just silly, we might as well just use -nodebug
>> by default all the time. (I mean, really, the amount of useful
>> stuff that -debug has caught versus the sheer amount of noise it
>> generates is just ridiculous.)
>> 
>> Alternately, since we now have no-frozen-rawhide, maybe we just 
>> institute a policy where rawhide runs with -debug on permanently,
>> and we flip the switch when we branch on released kernels. 90% of
>> the benefits from -debug will get caught then, and the other 10%
>> wouldn't've got caught anyway since the bugs won't even be found
>> until three weeks after release when there's now a couple hundred
>> thousand people running it.
> 
> I think I'm with Kyle here, leave rawhide always debug and go split
> at branch time. Competent bug reporters will happily grab
> kernel-debug if required, perf people won't test until branch time
> most of the time anyway, I suspect. Less people running a
> debug-enabled kernel without realizing it (eg, F14 base kernels up
> until earlier today) could help SNR too.

Well, I had originally floated this idea when wishing for more
(performance) testing closer to upstream, and I thought that for some
corners of the testing universe, having packaged prerelease/upstream
kernels in rawhide would be good for that, if they weren't bogged down
by tons of debug options.

But I also said something like "but we don't have to go forward with
this until we actually have some plan to use the nondebug variants." :)

-Eric