Re: GNOME needs VA's help?

[sml13 cornell edu]

On 17 Dec 1998, Elliot Lee wrote:

> On Thu, 17 Dec 1998 16:01:12 -0500 (EST), sml13@cornell.edu
> <sml13@cornell.edu> wrote:
> 

 [ blah, blah, blah ]

> >back-breaking labor for any lesser system :-)  If, however, we could set 
> >up a dual-processor VA YMP server (with the latest 2.1.xxx SMP Linux 
> >kernel) to do these builds around the clock, I think that the Gnome 
> >source tree would see an exponential rise in stability.
> 
> I disagree.
> 
> Compilation problems _usually_ result from incorrect versions of
> prerequisites, or other environmental conditions, NOT from the tree itself
> being broken.

Touche.  I didn't me to put any developers on the defensive.  Considering 
that I have contributed no code to the main tree yet, it would be perfectly 
fine if you were to tell me to go @#$! myself :-)  Or maybe contribute 
something other than rambling prose.  And I would have to agree that 
many of the compilation problems that I have run into were more a 
result of my ignorance than any "bugs" in the code.  But...

> 
> GNOME will be stable when it runs stably, not when it compiles stably. 

...compiling stably is a necessary pre-requisite to running stably, no?

> We
> need people to do testing, create test procedures, and write test programs
>:) Anyone have suggestions?

Yes, I have one actually.  We (me, anyone else) could -- and I think 
someone else suggested this earlier -- develop test suites for 
components that are run by Tinderbox (look at the orange entries on 
http://cvs-mirror.mozilla.org/webtools/tinderbox/showbuilds.cgi?tree=raptor) that report when items built successfully but then failed to perform as expected.  I think someone suggested this in reference to contributed widgets to GTK.  The person who writes a new module would write a little test (fairly comprehensive, ideally, but I don't know exactly how this is done with graphical apps?  intercept X signals/drawing information and comparing it against some ideal?  I'll have to find out what the Mozilla folk are doing in this regard)  

With graphical apps, maybe the only %100 reliable way to do testing is by 
sitting people with no lives like myself in front of a screen and having 
them poke the applet/application until we can get it to crash (as I do).  
But 
wouldn't it be cool if we could somehow automate some of that stuff so 
that it could run unattended and then automatically report back to a 
website whether or not it is working as expected!?  Again, maybe the 
Mozilla folks could share some thoughts on how they test their (very 
graphical) product with Tinderbox

shane

> 
> -- Elliot
> "In film you will find four basic story lines. Man versus man, man
>  versus nature, nature versus nature, and dog versus vampire."
>     - Steven Spielberg
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
> 
>