[Xenomai-core] [RFC] collecting xenomai statistics

[Xenomai-core] [RFC] collecting xenomai statistics

[Niklaus Giger]

Hi

Following a suggestion from Philippe Gerum I propose to collect and prepare 
like this:

a) Make it easy to collect information

add -s/-c option to xeno-test, help text would look like 
-s         send output of xeno-test to xeno-stat@domain.hid
-c <name>  if -s, send also kernel config file to xeno-stat@domain.hid
(May be patch xeno-config to emit also the revision of the svn checkout?)

b) Setup an e-mail account xeno-stat@domain.hid.

c) Add a archiver which generates daily a gzipped tar file of all messages 
ever sent to xeno-stat@domain.hid (e.g. of its mbox). Make it available 
somewhere on the internet.

d) Write a converter the raw messages into more suitable representation, eg. a 
MySQL-DB, a spreadsheet format. Extract the raw message and kernel config and 
store the publicly accessible on the internet. The DB/spreadsheet will 
contain pointers (URLs) to the raw message/kernel config.

e) Write viewers which present interesting statistics. E.g. X/HTML pages to 
present a ordered (by architecture, board, version, etc) view of the 
available  results.

I would like to advance like this:

I am not interested in step a), as it is easy for me just to write a trivial 
script to sent the xeno-test output to any address. Also adding the revision 
of svn checkout is not very difficult.

For point b+c) I am lacking the necessary rights, but it easy for me to setup 
a similar account for my tests here. But I would appreciate, if somebody of 
the core team would help me to get this work done.

For point d+e) I will (after a week of vacation with my son) invest some work. 
But I would be very interested in knowing exactly which kind of information 
the core developers are interested in. How should it be presented? In tabular 
form? Graphs, which ones? And kind of feedback will be evaluated and 
integrated.

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] [RFC] collecting xenomai statistics

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]

Niklaus Giger wrote:
> Hi
> 
> Following a suggestion from Philippe Gerum I propose to collect and prepare 
> like this:
> 
> a) Make it easy to collect information
> 
> add -s/-c option to xeno-test, help text would look like 
> -s         send output of xeno-test to xeno-stat@domain.hid
> -c <name>  if -s, send also kernel config file to xeno-stat@domain.hid
> (May be patch xeno-config to emit also the revision of the svn checkout?)
> 
> b) Setup an e-mail account xeno-stat@domain.hid.
> 
> c) Add a archiver which generates daily a gzipped tar file of all messages 
> ever sent to xeno-stat@domain.hid (e.g. of its mbox). Make it available 
> somewhere on the internet.
> 
> d) Write a converter the raw messages into more suitable representation, eg. a 
> MySQL-DB, a spreadsheet format. Extract the raw message and kernel config and 
> store the publicly accessible on the internet. The DB/spreadsheet will 
> contain pointers (URLs) to the raw message/kernel config.
> 
> e) Write viewers which present interesting statistics. E.g. X/HTML pages to 
> present a ordered (by architecture, board, version, etc) view of the 
> available  results.

Do you know http://issaris.org/rtai (the RTAI LiveCD)? It's no longer
maintained but may still contain useful ideas, and Takis (Panagiotis
Issaris) will likely be happy to answer questions on details of his
approach.

> 
> I would like to advance like this:
> 
> I am not interested in step a), as it is easy for me just to write a trivial 
> script to sent the xeno-test output to any address. Also adding the revision 
> of svn checkout is not very difficult.
> 
> For point b+c) I am lacking the necessary rights, but it easy for me to setup 
> a similar account for my tests here. But I would appreciate, if somebody of 
> the core team would help me to get this work done.
> 
> For point d+e) I will (after a week of vacation with my son) invest some work. 
> But I would be very interested in knowing exactly which kind of information 
> the core developers are interested in. How should it be presented? In tabular 
> form? Graphs, which ones? And kind of feedback will be evaluated and 
> integrated.
> 

I think starting with what Takis once collected would be more than
enough for a first round.

I cannot provide you access to the infrastructure, but I vote for
granting it. Great commitment!

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] [RFC] collecting xenomai statistics

[Jim Cromie]

Niklaus Giger wrote:
> Hi
>
> Following a suggestion from Philippe Gerum I propose to collect and prepare 
> like this:
>
> a) Make it easy to collect information
>
> add -s/-c option to xeno-test, help text would look like 
> -s         send output of xeno-test to xeno-stat@domain.hid
> -c <name>  if -s, send also kernel config file to xeno-stat@domain.hid
>   
attached patch adds new -m -M flags for xeno-test, (-s flag is taken, 
for statistics)
former for a fixed addy (to be patched later), latter taking any email 
as arg.

I didnt add -c <name>, since xeno-test already does something similar;
if you build with CONFIG_IKCONFIG_PROC=y, xeno-test greps XENO out of 
/proc/config.gz
(probably needs a few more grep terms, and perhaps a -verbose mode which
cats the whole thing.)

The -M option works, since I just received an email Id sent earlier,
but I also sent one to xenomai-core, and it hasnt shown up yet.
I suspect that the mail looks like spam, and has been rejected,
since my hostname is not a real FQDN.
So Im not so sure that email is the best way here, but it is 
conceptually simple.

( back in Nov, I set up a gmail acct, and tried to fetch mail from it 
with a script.
gmail wants TLS security, and didnt let me in, so I punted/shelved this. )
Niklaus' message brought me back on this topic.


So Im considering poaching code from LiveCD that does url-encoding,
or just using curl to post to some file-upload url.
How would you do this if you only had busybox ??

Anyway, both email and url-upload are suboptimal wrt spam,
latter is also a server support issue.



> (May be patch xeno-config to emit also the revision of the svn checkout?)
>
>   
perhaps as a 4th number on the version, that way xeno-config can stay as is.

[root@domain.hid bin]# ./xeno-config --version
2.1.50
Id like instead:
2.1.50.941

This seems better than pokinh around a filesystem, looking for the 
xenomai svn
(which may be on the build-host, not the run-host)


> b) Setup an e-mail account xeno-stat@domain.hid.
>
>   
getting messages thru the anti-spam filters is the issue here,

> c) Add a archiver which generates daily a gzipped tar file of all messages 
> ever sent to xeno-stat@domain.hid (e.g. of its mbox). Make it available 
> somewhere on the internet.
>   
or a daily/weekly digest/tarball

> d) Write a converter the raw messages into more suitable representation, eg. a 
> MySQL-DB, a spreadsheet format. Extract the raw message and kernel config and 
> store the publicly accessible on the internet. The DB/spreadsheet will 
> contain pointers (URLs) to the raw message/kernel config.
>   
certainly not a bad idea.  Will simplify collection/selection of 
data-sets for various things,
esp more complicated selections (with ands, ors, etc). 

> e) Write viewers which present interesting statistics. E.g. X/HTML pages to 
> present a ordered (by architecture, board, version, etc) view of the 
> available  results.
>
>   

Ive done minimal dabbling with gnuplot, R, both have possibilities.

With gnuplot, I tried graphing the RTD data, failed cuz theres no time 
column
(couldnt figure out how to create/infer a synthetic 'index' column).
It has some capability to select data out of files using awk,etc 
subcommands,
but for complicated data files like xeno-test outputs (multiple 
sections, different formats),
I think it (the selection, reformating capabilities) might be over-matched.


R can apparently manage complex data-sets, and select data out of them.
It sounds tremendously capable (after the learning curve)
That said, Ive not grokked its use yet.

[Xenomai-core] [patch] xeno-test email addition

[Jim Cromie]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Jim Cromie wrote:
> Niklaus Giger wrote:
>> Hi
>>
>> Following a suggestion from Philippe Gerum I propose to collect and 
>> prepare like this:
>>
>> a) Make it easy to collect information
>>
>> add -s/-c option to xeno-test, help text would look like -s         
>> send output of xeno-test to xeno-stat@domain.hid
>> -c <name>  if -s, send also kernel config file to xeno-stat@domain.hid
>>   
> attached patch adds new -m -M flags for xeno-test, (-s flag is taken, 
> for statistics)
> former for a fixed addy (to be patched later), latter taking any email 
> as arg.
>
> I didnt add -c <name>, since xeno-test already does something similar;
> if you build with CONFIG_IKCONFIG_PROC=y, xeno-test greps XENO out of 
> /proc/config.gz
> (probably needs a few more grep terms, and perhaps a -verbose mode which
> cats the whole thing.)
>
> The -M option works, since I just received an email Id sent earlier,
> but I also sent one to xenomai-core, and it hasnt shown up yet.
> I suspect that the mail looks like spam, and has been rejected,
> since my hostname is not a real FQDN.
> So Im not so sure that email is the best way here, but it is 
> conceptually simple.



Oof.  Now attached.

[-- Attachment #2: patch-mail --]
[-- Type: text/plain, Size: 1495 bytes --]

Index: scripts/xeno-test.in
===================================================================
--- scripts/xeno-test.in	(revision 943)
+++ scripts/xeno-test.in	(working copy)
@@ -17,6 +17,8 @@
   -L	     	writes to logfile (default "test-`uname -r`") (via script)
   -N <name>	same as -L, but prepend "$name-" (without -L, logname="$name-")
 		prepending allows you to give a full path.
+  -m		sends output file to xeno-test@domain.hid
+  -M <email>	sends output file to given addy
 
   # following options are passed thru to latency, klatency
   -s	print statistics of sampled data (default on)
@@ -136,8 +138,11 @@
 logprefix=
 prepost=	# command to run pre, and post test (ex ntpq -p)
 
-while getopts 'd:shqT:l:H:B:uLN:w:W:p:' FOO ; do
+email='xeno-test@domain.hid'
+sendit=
 
+while getopts 'd:shqT:l:H:B:uLN:w:W:p:mM:' FOO ; do
+
     case $FOO in
 	s|h|q)
 	    pass="$pass -$FOO" ;;
@@ -166,6 +171,11 @@
 	p)
 	    prepost=$OPTARG 
 	    loadpass="$loadpass -p '$OPTARG'"  ;;
+	M)
+	    email=$OPTARG 
+	    sendit=1 ;;
+	m)
+	    sendit=1 ;;
 	?)
 	    myusage ;;
     esac
@@ -179,6 +189,10 @@
     # restart inside a script invocation, passing all
     date=`date +%y%m%d.%H%M%S`
     script -c "./xeno-test $loadpass $pass $*" "$logprefix$logfile-$date"
+    if [ $sendit == 1 ]; then
+	echo "mailing $logprefix$logfile-$date to $email"
+	mail -s 'xeno-test results' $email < "$logprefix$logfile-$date"
+    fi
 else
     if [ "$altwork" != "" ]; then
 	mkload() { exec $altwork; }

Re: [Xenomai-core] [patch] xeno-test email addition

[Philippe Gerum]

Jim Cromie wrote:
> Jim Cromie wrote:
> 
>> Niklaus Giger wrote:
>>
>>> Hi
>>>
>>> Following a suggestion from Philippe Gerum I propose to collect and 
>>> prepare like this:
>>>
>>> a) Make it easy to collect information
>>>
>>> add -s/-c option to xeno-test, help text would look like -s         
>>> send output of xeno-test to xeno-stat@domain.hid
>>> -c <name>  if -s, send also kernel config file to xeno-stat@domain.hid
>>>   
>>
>> attached patch adds new -m -M flags for xeno-test, (-s flag is taken, 
>> for statistics)
>> former for a fixed addy (to be patched later), latter taking any email 
>> as arg.
>>
>> I didnt add -c <name>, since xeno-test already does something similar;
>> if you build with CONFIG_IKCONFIG_PROC=y, xeno-test greps XENO out of 
>> /proc/config.gz
>> (probably needs a few more grep terms, and perhaps a -verbose mode which
>> cats the whole thing.)
>>
>> The -M option works, since I just received an email Id sent earlier,
>> but I also sent one to xenomai-core, and it hasnt shown up yet.
>> I suspect that the mail looks like spam, and has been rejected,
>> since my hostname is not a real FQDN.
>> So Im not so sure that email is the best way here, but it is 
>> conceptually simple.
> 
> 
> 
> 
> Oof.  Now attached.
> 

Applied, thanks.

-- 

Philippe.

Re: [Xenomai-core] [patch] xeno-test email addition

[Romain Lenglet]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

Philippe Gerum wrote:
> Jim Cromie wrote:
> > Jim Cromie wrote:
> >> Niklaus Giger wrote:
> >>> Hi
> >>>
> >>> Following a suggestion from Philippe Gerum I propose to
> >>> collect and prepare like this:
> >>>
> >>> a) Make it easy to collect information
> >>>
> >>> add -s/-c option to xeno-test, help text would look like
> >>> -s send output of xeno-test to xeno-stat@domain.hid -c
> >>> <name>  if -s, send also kernel config file to
> >>> xeno-stat@domain.hid
> >>
> >> attached patch adds new -m -M flags for xeno-test, (-s flag
> >> is taken, for statistics)
> >> former for a fixed addy (to be patched later), latter
> >> taking any email as arg.
> >>
> >> I didnt add -c <name>, since xeno-test already does
> >> something similar; if you build with
> >> CONFIG_IKCONFIG_PROC=y, xeno-test greps XENO out of
> >> /proc/config.gz
> >> (probably needs a few more grep terms, and perhaps a
> >> -verbose mode which cats the whole thing.)
> >>
> >> The -M option works, since I just received an email Id sent
> >> earlier, but I also sent one to xenomai-core, and it hasnt
> >> shown up yet. I suspect that the mail looks like spam, and
> >> has been rejected, since my hostname is not a real FQDN.
> >> So Im not so sure that email is the best way here, but it
> >> is conceptually simple.
> >
> > Oof.  Now attached.
>
> Applied, thanks.

Here is its little brother patch which updates the manpage.

-- 
Romain LENGLET

[-- Attachment #2: xeno-test-newoptions_2006-04-19.patch --]
[-- Type: text/x-diff, Size: 3467 bytes --]

--- xenomai/ChangeLog	2006-04-19 12:30:32.503520224 +0900
+++ xenomai-xenotestmail/ChangeLog	2006-04-19 12:49:28.379840776 +0900
@@ -1,3 +1,8 @@
+2006-04-19  Romain Lenglet <rlenglet@domain.hid>
+
+	* doc/man/xeno-test.man.in: Add documentation for the new -m and -M
+	options added to the xeno-test script.
+
 2006-04-18  Jim Cromie <jim.cromie@domain.hid>
 
 	* scripts/xeno-test.in: Add -[Mm] options for automated
--- xenomai/doc/man/xeno-test.man.in	2006-03-28 14:12:36.109329864 +0900
+++ xenomai-xenotestmail/doc/man/xeno-test.man.in	2006-04-19 12:48:53.585130376 +0900
@@ -9,11 +9,11 @@
 .\" Xenomai distribution.
 .\"
 .pc
-.TH XENO-TEST 1 "2005-10-19" "@PACKAGE_VERSION@" "Xenomai"
+.TH XENO-TEST 1 "2006-04-19" "@PACKAGE_VERSION@" "Xenomai"
 .SH NAME
-xeno\-test \- Tests and mesures the performance of a Xenomai installation
+xeno\-test \- Tests and measures the performance of a Xenomai installation
 .SH SYNOPSIS
-\fBxeno\-test\fP [\fB\-w\fP \fIworkloads\fP] [\fB\-d\fP \fIdevice\fP] [\fB\-W\fP \fIcommand\fP] [\fB\-p\fP \fIcommand\fP] [\fB\-L\fP [\fB\-N\fP \fIprefix\fP]] [\fB\-s\fP] [\fB\-l\fP \fIsamples\fP] [\fB\-h\fP [\fB\-H\fP \fIcategories\fP] [\fB\-B\fP \fIgranularity\fP]] [\fB\-T\fP \fIseconds\fP [\fB\-q\fP]] [\fB\-\-\fP] [\fIargs\fP] ...
+\fBxeno\-test\fP [\fB\-w\fP \fIworkloads\fP] [\fB\-d\fP \fIdevice\fP] [\fB\-W\fP \fIcommand\fP] [\fB\-p\fP \fIcommand\fP] [\fB\-L\fP [\fB\-N\fP \fIprefix\fP]] [\fB\-m\fP | \fB\-M\fP \fIemail\fP] [\fB\-s\fP] [\fB\-l\fP \fIsamples\fP] [\fB\-h\fP [\fB\-H\fP \fIcategories\fP] [\fB\-B\fP \fIgranularity\fP]] [\fB\-T\fP \fIseconds\fP [\fB\-q\fP]] [\fB\-\-\fP] [\fIargs\fP] ...
 .SH DESCRIPTION
 \fBxeno\-test\fP measures the performance of Xenomai, by executing Xenomai's \fBlatency\fP and \fBklatency\fP tests while generating a high workload on the system.
 The default command that is executed to simulate workload (if no alternate command is specified with a \fB-W\fP \fIcommand\fP option) is:
@@ -29,6 +29,8 @@
 
 If an invalid option is specified, \fBxeno\-test\fP prints out an usage help message and exits.
 
+You are strongly encouraged to use the \fB\-m\fP option, to anonymously help the Xenomai team collecting statistics about Xenomai's performance on the widest range of systems.
+
 .SH OPTIONS
 These following options are specific to \fBxeno\-test\fP:
 .TP
@@ -55,6 +57,12 @@
 \fB\-N\fP \fIprefix\fP
 Prepends \fIprefix\fP\fB\-\fP to the log file name, hence if the \fB\-L\fP option is also specified the log file name is \fIprefix\fP\fB\-test\-\fP\fIkernel_release\fP.
 This option is useful to create the log file in a different directory, by specifying a \fIprefix\fP that starts with the relative path to that directory.
+.TP
+\fB\-m\fP
+Sends the results of the tests to the Xenomai team's email address, to help collecting statistics about Xenomai's performance. The email is sent using the system's mail(1) command.
+.TP
+\fB\-M\fP \fIemail\fP
+Sends the results of the tests to the specified email address. The email is sent using the system's mail(1) command.
 .PP
 The following options are directly passed to the \fBlatency\fP and \fBklatency\fP test commands executed by \fBxeno\-test\fP.
 If no such options are specified, the \fB\-s \-T 10 \-q\fP options are passed by default by \fBxeno\-test\fP.
@@ -111,5 +119,8 @@
 .BR uname (1)
 .SH HISTORY
 .TP
+2006-04-19
+Updated to document the new -m and -M options.
+.TP
 2005-10-19
 Written by Romain Lenglet <rlenglet@domain.hid>

Re: [Xenomai-core] [patch] xeno-test email addition

[Philippe Gerum]

Romain Lenglet wrote:
>>>>The -M option works, since I just received an email Id sent
>>>>earlier, but I also sent one to xenomai-core, and it hasnt
>>>>shown up yet. I suspect that the mail looks like spam, and
>>>>has been rejected, since my hostname is not a real FQDN.
>>>>So Im not so sure that email is the best way here, but it
>>>>is conceptually simple.
>>>
>>>Oof.  Now attached.
>>
>>Applied, thanks.
> 
> 
> Here is its little brother patch which updates the manpage.

Applied, thanks.

-- 

Philippe.

Re: [Xenomai-core] [patch] xeno-test email addition

[Jim Cromie]

Philippe Gerum wrote:
> Romain Lenglet wrote:
>>>>> The -M option works, since I just received an email Id sent
>>>>> earlier, but I also sent one to xenomai-core, and it hasnt
>>>>> shown up yet. I suspect that the mail looks like spam, and
>>>>> has been rejected, since my hostname is not a real FQDN.
>>>>> So Im not so sure that email is the best way here, but it
>>>>> is conceptually simple.
>>>>
>>>> Oof.  Now attached.
>>>
>>> Applied, thanks.
>>

Doh - small err. 
if [ $sendit = 1 ] needs quotes around the var, for when its undeffd.
will patch soon.

Im looking for other things to add, in part to prevent a changelog entry 
that says
"fixed a dumb tested-new-but-not-old, so bug got out" entry :-/

- change the prewired -m email-addy ?  (to xeno-stats@domain.hid)
- add From: header to get past subscriber-only check.
    should this be a prewired addy (forex  xeno-test-output@domain.hid)
    or the user's name ( if so, which ENVAR should we use ?  XENO_USER ?)
- verbose (send whole config atm, perhaps others later)
- run xeno-info, xeno-config
- grep more config-items out of config (for non-verbose mode)
    latency-killers presumably, PREEMPT, others ?
- NPTL availability (kinda overkill, since its absence when needed is 
already detected)

Can anyone think of other possibly useful raw data ?
I think Ive already got everything that LiveCD collected, plus some.


thanks
jimc


PS.  Is "Engines of Creation" another Joe Satriani album ?

PPS.    the dude can *rip* a fretboard.  In "real-time"

PPPS.  I bet Philippe plays a mean air-guitar ;-)

Re: [Xenomai-core] [patch] xeno-test email addition

[Philippe Gerum]

Jim Cromie wrote:
> Philippe Gerum wrote:
> 
>> Romain Lenglet wrote:
>>
>>>>>> The -M option works, since I just received an email Id sent
>>>>>> earlier, but I also sent one to xenomai-core, and it hasnt
>>>>>> shown up yet. I suspect that the mail looks like spam, and
>>>>>> has been rejected, since my hostname is not a real FQDN.
>>>>>> So Im not so sure that email is the best way here, but it
>>>>>> is conceptually simple.
>>>>>
>>>>>
>>>>> Oof.  Now attached.
>>>>
>>>>
>>>> Applied, thanks.
>>>
>>>
> 
> Doh - small err. if [ $sendit = 1 ] needs quotes around the var, for 
> when its undeffd.
> will patch soon.
> 
> Im looking for other things to add, in part to prevent a changelog entry 
> that says
> "fixed a dumb tested-new-but-not-old, so bug got out" entry :-/
> 
> - change the prewired -m email-addy ?  (to xeno-stats@domain.hid)
> - add From: header to get past subscriber-only check.
>    should this be a prewired addy (forex  xeno-test-output@domain.hid)
>    or the user's name ( if so, which ENVAR should we use ?  XENO_USER ?)
> - verbose (send whole config atm, perhaps others later)
> - run xeno-info, xeno-config
> - grep more config-items out of config (for non-verbose mode)
>    latency-killers presumably, PREEMPT, others ?

I'd say stuff from the kernel hacking section adding overhead including 
to primary mode threads, like CONFIG_DEBUG_SPINLOCK, 
CONFIG_FRAME_POINTER, and friends. And also those Adeos switches: 
CONFIG_IPIPE_STATS, CONFIG_IPIPE_TRACE.

> - NPTL availability (kinda overkill, since its absence when needed is 
> already detected)
> 
> Can anyone think of other possibly useful raw data ?
> I think Ive already got everything that LiveCD collected, plus some.
> 

Which should be enough to start something sensible, I guess.

> 
> thanks
> jimc
> 
> 
> PS.  Is "Engines of Creation" another Joe Satriani album ?
> 

Yes, released in Y2K.

> PPS.    the dude can *rip* a fretboard.  In "real-time"
> 

Satch plays faster than I can code, which is ok since he does it better too.

> PPPS.  I bet Philippe plays a mean air-guitar ;-)
> 

Nope. Philippe is going to call Vai, Petrucci, Lukather, Van Halen and a 
few others to the rescue, so that the air shivers while the keyboard 
suffers.

-- 

Philippe.

Re: [Xenomai-core] [RFC] collecting xenomai statistics

[Gilles Chanteperdrix]

Jim Cromie wrote:
 > The -M option works, since I just received an email Id sent earlier,
 > but I also sent one to xenomai-core, and it hasnt shown up yet.

In order to avoid spam, the xenomai-core list probably only accept mail
from registered members.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] [RFC] collecting xenomai statistics

[Gilles Chanteperdrix]

Jim Cromie wrote:
 > perhaps as a 4th number on the version, that way xeno-config can stay as is.
 > 
 > [root@domain.hid bin]# ./xeno-config --version
 > 2.1.50
 > Id like instead:
 > 2.1.50.941
 > 
 > This seems better than pokinh around a filesystem, looking for the 
 > xenomai svn
 > (which may be on the build-host, not the run-host)

If you want to change the version returned by xeno-config, simply modify
config/version and re-run scripts/bootstrap before building Xenomai.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] [RFC] collecting xenomai statistics

[Gilles Chanteperdrix]

Niklaus Giger wrote:
 > But I would be very interested in knowing exactly which kind of information 
 > the core developers are interested in. How should it be presented? In tabular 
 > form? Graphs, which ones? And kind of feedback will be evaluated and 
 > integrated.

I did some similar work once, so I have some ideas. What I
would like to have is, given a configuration (.config) build all
versions of Adeos+Xenomai for a given set of compilers. Then, present
the result in a tabular form. Each cell would give the number of
warnings and errors for the corresponding build, with links to
browseable build logs. Maybe the cell could have different colors
(green, orange, red) depending on the number of warnings and errors.

What would also be interesting, is to test the "distcheck" target. The
interesting result being a comparison between the source directory
contents and the generated tarball contents (if distcheck is
successful).

-- 


					    Gilles Chanteperdrix.