* Sam Ravnborg <sam@ravnborg.org> wrote:

quoted text
> And asking me to do randconfig is not an option. I have only this 
> machine to work on and with a -j8 build it gets unresponsive at least 
> so much that it irritates me.

quoted text
> > More defconfigs would just be a constant maintenance drag, they are 
> > rather pointless on PC hardware anyway (we'd have to have at least a few 
> > hundred of them for it to be meaningful as a "default config") and it 
> > does not really solve the problem either.
>
> 10 different configs would cover what I have in mind. This is not all 
> sort of combinations of dirvers and kernel haching options multiplied 
> with the arch specific options. This is the typical set of options 
> that is used to build a kernel to the relevant sub-architectures.
> 
> And an occasional defconfig update are not a maintanence burden.
> 
> It is a simple equation: 10 additional defconfigs can give you more 
> build coverage by additional people. Is it worth it?

i dont think it's worth it on x86, because it has no real meaning so it 
will just be an arbitrary thing that deteriorates over time.

Subarchitectures on x86 are just a shortcut for the "0.1% of systems 
that were lazy to be properly abstracted into the general PC code". We 
are discouraging additional subarches and the one that got added 
recently will go away soon. The rest is legacy.

Really, we should concentrate our testing to where our _testers_ are and 
where our developers are.

And according to lkml, http://kerneloops.org and a 300,000+ sample 
http://smolt.fedoraproject.org/static/stats/stats.html statistics, our 
testers are distributed like this:

 - more than 90% of all kernel developers use general PC hardware

 - more than 95% of our active testers use general PC hardware

 - more than 99.1% of our distro users that are willing to send us
   feedback use general PC hardware as well

(In that aspect i dont count the million(s?) of non-x86 Linux based 
phones as "a million users", unless they become an active part of our 
ecosystem and do things like hook into kerneloops.org. It's that simple, 
really.)

	Ingo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/