On Mon, 15 Oct 2007, Lars Marowsky-Bree wrote: > Hi David, > > that is a good suggestion, I like the principle.
Thanks for the acknowledgement and reply, Lars. > A central build service such as provided by the openSUSE project has the > advantage of tighter control over what is actually compiled in what > environment, which does have some consistency advantages. (It can also > be installed locally, too.) But a build service from a more diverse community can more quickly and readily pick up those strange inter-package interactions (and weaknesses in our "configure.in" etc.) that crop up from time to time. The strength of a gene-pools lies in its diversity. > The major advantage of buildbot seems to be automated feedback by > e-mail; this is supposedly forthcoming for openSUSE as well, and I can > ping the team to raise the priority of this. And, of course, > testing build architectures not supported by the central site. And the "update X caused failure Y" (or "He's the one who broke it!") feature can be useful. > However, I don't think the recompile cycle is where we spot most of our > bugs. [...] 1. "of our bugs" -> "of the Linux/32bit subset of bugs". 2. But we still get a significant number, even on Linux. In the last couple of years, I've fixed several updates which were apparently OK for their contributor (who presumably tested on 32-bit Linux) but have failed to build on 64-bit Linux. A routine, automated, regular build cycle would quickly spot these (and apportion blame, if you're that way inclined!). 3. A compiler warning/error from one architecture can often reveal a general lurking bug missed by another architecture. > [...] The problem which buildbot doesn't seem to address is automated > roll-out of the packages to a test cluster, and providing automated CTS > feedback. > > Or does it? I think that still needs to be scripted ... True. From my reading (and it is just reading, very little hand-to-hand combat with buildbot) it is about building (and perhaps "make test"?) rather than about roll out and run-time. But its build/test (or its equivalent) could still be worth having. > I'd be very interested in seeing that part addressed; automated download > + testing, ranging from BasicSanityCheck to CTS (where applicable) or > manual test cases, and returning the feedback to us as automatic as > possible. (Of course, that's a large order - any small step in that > direction would be welcome!) Thinking more laterally... could we improve our own "make test" (i.e. before we get to install/BSC) capabilities? There is a little under "lib/clplumbing"; might there be scope for more, across the Linux-HA software? > With regard to the build infrastructure, I do not currently think this > is our largest problem - we seem to have a working build infrastructure > available, and I think effort might be better spend on addressing needs > which are not met at all yet. I take the point. I presume buildbot and your openSuse cover similar, but probably not exactly the same, territory. With a centrally-run buildbot, we (developer-like people and other keen volunteers) could contribute in our own machines, with their subtleties of architectures, OSes, OS-releases, environments, conventions, etc. Can we do that with openSuse? (Let me know! I'll seek permission from the PHBs to join!) All the best. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
