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

[Niels Grewe]

Hi guys,

Am 01.04.2012 08:37, schrieb Dr. H. Nikolaus Schaller:
> Hi Greg,
> 
> Am 01.04.2012 um 02:27 schrieb Gregory Casamento:
> 
>> All of this defeats the purpose of the thing.  I don't want to do all of 
>> this work setting jenkins up only to make it easy for people to ignore by 
>> putting it on a mailing list which has no subscribers.
>>
>> I would insist that, if another list is created, that all of the current 
>> maintainers subscribe to it to ensure that the message gets out when someone 
>> breaks the build. 
>>
>> It is beneficial for as many people to know that the build is broken as 
>> possible so that it can be corrected by either the responsible party or by 
>> someone who Is knowledgeable enough to fix the problem.  There have, in the 
>> past, been regressions which have persisted for months without being 
>> discovered.  This system will help that never to happen again.  It does no 
>> good to have Jenkins announce issues with the build if no one hears about it.
> 
> 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.

> And if someone of these does not want to see the reports, it can be 
> questioned why he/she has write access...

I second that. My impression is that the people with svn write access
usually care enough about the project so that they are not indifferent
if their contributions cause breakage for other people. I'm fine with
subscribing to another list and monitoring it for problems that I caused
or can help with fixing. I expect that most hiccups can be easily
resolved, and it might not be desirable to further skew the SNR on
gnustep-dev with those. If noone picks up the pieces on a hypothetical
gnustep-ci (or whatever) mailing list, we can always escalate the
problem to gnustep-dev.

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.

Cheers,

Niels

signature.asc
Description: OpenPGP digital signature