Laszlo (Laca) Peter writes: > > In other words, if your consolidation depends on foo-1.2.3 and you > > need to upgrade to foo-1.2.4, things are simple if you can do that as > > an atomic 'putback' or 'commit' to a single consolidation's > > repository. You (and your customers) are in a world of hurt if you > > need to do that to multiple repositories, particularly so if there are > > incompatible changes involved. > > I not following why I would need to commit to multiple repositories.
I guess I didn't describe the situation in sufficient detail. In this hypothetical situation, you have a project, call it "Bar" that's delivered via consolidation "JDS." Bar depends on things provided by project "Foo" in consolidation "GNU." Currently, the version of Foo is foo-1.2.3. Due to changes in Bar, you now depend on a newer version of Foo. You thus want to have foo-1.2.4 (the 1.2.3 version doesn't work) in the WOS. In order to make this happen, you've got to make sure that foo-1.2.4 gets committed to the GNU consolidation before the new Bar gets committed to JDS, and then delivered via GNU before it's delivered via JDS. (Note that separate consolidations will have separate build schedules and may have separate integration schedules.) You also need to make sure (somehow!) that users who get the new Bar also get the new Foo -- though we have few mechanisms available to make sure that happens. Things are worse still if foo-1.2.4 has changes that are incompatible with foo-1.2.3. (This does happen with some open source projects; they don't all seem to use release numbering the same way we do.) In that case, you've got to make sure that the user _atomically_ updates both Foo and Bar at the same time, and that if the user needs to revert one, he reverts both. That's substantially harder to do. > "foo" would still be in one repository only. However, most of the > build tools that I'm talking about affect more than just one > consolidation. Sure. As long as they're fairly stable and mundane things (such as libtool), there's no likely problem here. If they're more exotic things (perhaps such as libxml), then we may well have problems. > > Yes, there is a reason to exclude them: the ARC approval for /usr/gnu > > was for things on that list, and no others. > > And that's fine, it just means that things not on that list cannot > go into /usr/gnu. They can still go into /usr if there is no > conflict. Right; per 2005/185. > > I doubt it. These sound like the most trivial of fast-tracks to > > me. Most are probably closed-approved-automatic. > > You mean if the fast-track only deals with the name space and not > with the technology itself? No. That's not really the point. When you have a project that does something obvious enough that no discussion about it is really warranted and all the issues have already been reviewed by some other project, then it may fall under "automatic approval" guidelines. See: http://www.opensolaris.org/os/community/arc/handbook/ This covers the case where we already have "N" of something, and "N+1" comes along. Provided that "N+1" follows all the norms for such things (it isn't deliberately doing something 'unusual'), it can be self-reviewed. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-discuss mailing list [email protected]
