Re: Jenkins build is back to normal : gnustep #12

[Riccardo Mottola]

Hi,

On 2012-04-01 10:11:37 +0200 Niels Grewe <address@hidden>  
wrote:

> > I see that you want to create a feedback loop, which is IMHO a very good 
> > means to stabilize the code quality.
> +1 I think it's an applaudable effort that Greg is taking here.

+1 for me too

> But I'd also like to call some attention to a problem that Fred
> mentioned when comparing this to Adam's test farm: Having one Jenkins
> instance that reports problems is far from enough, seeing that we do not
> only have a host of architectures and OSes to support, but at least two
> different compilers (gcc, clang), two runtimes, and whole bunch of ABIs
> (not to mention a cornucopia of optional features that might or might
> not cause issues). How are we going to tackle that? I think it would
> help tremendously if you, Greg, could post a howto so that everybody
> could replicate it for his or her favourite setup.

Well, it is true that it is not a catch-all. But we had sometimes in the  
past problems where header changes broke the build of core or of related  
apps.
So alread one Jenkin build is fine. The best would be probably to have  
32bit, 64bit, big & small endianness and gcc and clang. With that we would  
be quite safe.
On the fastest platform it would be nice to build also a couple of  
applications everytime: this would show if certain core changes break a  
couple of keya apps.

I'm fine with getting messages here: the messages should come only when  
the build breaks: this means that if everything is fine, nothing happens.  
Will we break it more than once a day? I hope not. Once broken, no further  
emails will coem until it get fixed.
Also, not only certain persons hould be mailed: If person X changes core  
and app of Y breaks, the problem needs to be analyzed by both: perhaps it  
was a workaround in the application that needs to be fixed or the change  
instead was wrong. It can't be known automatically!

Riccardo