Review Request: Build-infra M1

[Kelly O'Hair]

On Mar 22, 2012, at 4:51 PM, David Holmes wrote:

> Not wanting to go too OT here but I see the build-deps server as something to be used at most per machine rather than per developer. We have build servers internally that can be used by dozens of developers and we don't want multiple copies of toolsets. Even in the new build system I would expect to see the toolsets (for cross-compilation) installed on shared NFS mounts for use by these build servers. But at worse I would expect to have one installation per machine.

Unless it is done properly, having multiple developers updating a single machine copy of build dependency files
could be a disaster. Not all developers would be working on source bases with the exact same dependencies.
And NFS mounts create even more complications, creating a network dependence and similar update issues.

If you don't have control over these dependencies, every build you do could result in different bits, and if the
build dependencies do need to change, it's important that the individual developer knows that they did change,
and how to back it out or realize why things changed.

It has been my view that local disk space is not an issue on most modern systems, and having many copies is
not a problem if it is managed automatically and not manually, i.e. they really are the right copies.
Having it local and unique to that developer would provide the most predictable results, but only if we can get
the automatic install/update logic reliable.

I'm currently having a great deal of problem with our internal build&test system and it's all related to the systems
changing out from under us all the time. Automatic updates being installed, automatic virus definitions changing,
automatic defragmentation of the disks every week, services that keep other services running, and automatic reboots
for a variety of reasons. Virtual machines also come with mixed blessings, it's a complicated world.
Stability and predictability is hard in an ever changing world. So I'm frequently trying to make sure that we
are dealing with fewer variables and more constants, and if the constants need to change, change them carefully.

-kto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20120323/99bc1c42/attachment.htm>