On Fri, May 08, 2009 at 05:11:31PM -0500, Norm Jacobs wrote: >> So one way of dealing with that is not to upgrade the build machine's OS >> all the time, but only when absolutely required, to get a particular >> feature. And never to build with any of the SFW packages installed on the >> build machine. > > I guess that the way I see it, by upgrading the systems that folks build on > sooner, we are more likely to catch "accidental" dependencies up front and > more likely to get resolution either prior to integration or while the > responsible parties are more engaged.
But you won't have any accidental dependencies if you build on, say, a build 101 system -- you know precisely what's on the machine, and because nothing changes, no new dependencies can be introduced. Only when some component absolutely requires an OS upgrade do you have to do the work of finding out what new dependencies might have been introduced by building on a new base. You can constrain that CBE upgrade to once every six months, or once every OpenSolaris release or something, and components that need something newer will either have to wait, or integrate initially without that particular feature enabled. > Without upgrading more frequently, we are likely to miss several of the > "absolutely required" upgrades and just push the issues out. Upgrades of what, exactly? How often do we need a new version of a library or other component from outside SFW before some component in SFW can build at all? And could it just wait until some milestone? > That and I'm a masochist, so I tend to run the most current IPS or SVR4 > packaged bits on my system and often build things there. I suspect that > I'm not alone. :-\ Yes, it would mean that build machines wouldn't be able to have the latest and greatest bits on them, which means that engineers' desktops often wouldn't be able to be valid build machines. But that's why we have lab machines and virtualization environments. :) > As long as the mutt dependencies are accurate and granular enough, they > don't have to upgrade the entire OS. They only need to install/upgrade the > bits that mutt requires (and anything that results from those changes). > It's possible that those dependencies will require upgrading the entire OS, > but more often that is not the case. > FWIW, at least for SFW, I would really like to be tracking and auditing the > imported and exported interface changes at a more granular level so that we > get a better picture of the change that we are managing. Right, but if you build a component on build A, then those bits won't necessarily run on build A-n, even if it doesn't use any Public interfaces that were introduced in the meanwhile. Particularly when it comes to OSS. If you want the component to work on builds A-n ... A, you have to build on A-n. (Of course, this does require us to know what incompatibilities have been introduced in that time frame, but that's where the ARC should provide the most value.) Danek
