Hi,
On 2012-04-01 10:11:37 +0200 Niels Grewe <[email protected]>
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
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
