Date:	Wed, 25 Nov 1998 16:15:11 +0100 (CET)
From:	Arjan van de Ven <arjan@stack.nl>
To:	Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>, Brian Schau <bsc@fleggaard.dk>, Christof Damian <damian@mediaconsult.com>,
Subject: Kernel Compilation Project

Hi,


Thanks for your response to my proposal for a "Kernel Compilation
Project".

This message is intended to summarize the responses and give a progress
report.


Summary
=======

The common idea I get from the responses is that the thing should be
distributed. (if only for the different platforms Linux runs on)

There was a question about if all participents should use the _same_
compiler (i.e. gcc version 2.7.2.3.1.3.2.1.2.3.x) or that multiple
versions would be allowed. It is my opinion that the kernel should at
least _compile_ with all compiler-flavours, but to include the
compiler-version in a "bugreport" just to be sure. 

Someone answered that he prefered a fixed set of configurations over a
random set, I partially agree: If a configuration is known to fail, it
should be put in some queue and tried first when a new kernel is released.
If it succeeds, it can be moved to a "fixed" section and never be used
again. Also, some fixed variants (all options "Y" and all options "N" for
example) should be tried for every kernel too. 

About the math:
Some said that there were way to much options to ever test every
combination (no doubt about that) but the also true response was that a
certain option at most has some (let's say 5) other options it actually
depends/conflicts on, so trying about 64 kernels would make the
probability very small that something is missed.
64 seems a little on the small side (given that most options have 3
responses (Y/N/M) and most have a probability of 1/4 of beeing selected),
but the general idea is that the job is not _that_ endless.


Progress
========

I have set up a JitterBug bugtracking system on my website 
( http//www.stack.nl/~arjan/cgi-bin/KERNEL ) and a shellscript/C system
that produces a random config, compiles it and mails the result to the
jitterbug-page. This is not really distributed (the .config's are created
on the client) but it is a start. It is currently in "beta-test", to see
if it can run unattended. The compiles in the testset ran on a slow 486
(at work), I'll port them to my K6 at home, it should increase the number
of reports.

Planning
========
1)  Create a better system, distributed in that the configurations are
    created in a central location (this requires a linux-box with the
    kernel-sources and 24/7 net-connectivity)

2)  Multi-platform support (is it possible to do a make config for a
    different architecture?)

3)  Distribution of patches along with the .config (for "try this config
    on 2.1.130preXX")


Questions
=========
The following questions remain:

1)  How should the found problems be reported to Linus/Alan/...
2)  What would be nice distributed setup


Greetings,
  Arjan van de Ven


PS: If someone wants non-guest access to the jitterbug-system, email me
and I'll set up an account.



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