> And as for the limitations you mentioned: Thanks for this detailed summary. > Although: Different needs could also be addressed by a single system
In developing a distributed development system, one could use a one-size-fits-all approach, or one could step back and define the high level requirements that such a build system needs to adhere to and let each development organization come up with their own locally optimized solution. Sun intentionally did the latter. Specifically, the build process that takes source code and generates binary packages is completely delegated to the individual consolidation teams. The C-Teams are expected to manage the evolution of its source code (via the ARC process) and do whatever it takes to build and deliver binary packages. This means that the build system and the source code control system and the developer coordination system and the compilers and the editors and IDEs and ... can *all* evolve independently, and nobody is stuck behind an obsolete or ineffective system imposed from the outside. >From an "architecture of the development process" perspective, this is a very good thing. Along with the "policies" that all build systems deliver packages and that changes to the public interfaces exposed by those packages be coordinated thru the ARC process, there are several "best practices" that can be used by consolidations as they invent/evolve their own development processes. Any consolidation is free to come up with new and improved best practices in this area, but none are required to use any particular one. -John
