Just a quick note, for those not in the know. Sun policy requires (and for good reason!) that engineers with access to NDA materials from either AMD or Intel work only on the platform (either AMD or Intel) for which they got the NDA. Its too bad at some level, because there could (should?) be more sharing, especially given the fact that Intel and AMD will often have features that are the same (or very nearly so!) with only different names.
So there might be some divisions that seem rather artificial, but they have a legal CYA basis backed by Sun policy. Now where the information is not NDA (and oft times it is indeed public information) then there is no such problem. One of these days maybe we'll figure out how to get the lawyers out of the way of engineers, but that day is not today.... -- Garrett James Carlson wrote: > Herman, George writes: > >> After reading the description of community and project, it would seem >> that the option that best meets the project guidelines is number 2. (The >> guidelines seem clearly state that communities should sponsor projects, >> and not projects sponsor/create new projects.) >> > > I wasn't at all suggesting that you have your project "endorse" some > other project. > > Instead, I was suggesting that *if* your concern is that you have > multiple related subprojects and if those subprojects were all sharing > code and development, then it may well make sense to have a single > project with divided resources for the subprojects. The current > infrastructure supports such an organization, and there's low > overhead. > > You can certainly start a new community if you feel that's necessary. > The process for that is in the consititution, and requires OGB > approval, as described in article VII: > > http://www.opensolaris.org/os/community/ogb/governance/ > > You'll need to work through the issues described in 7.4, including the > trademark problem, to get this done. > > As for my comment on such a proposal, I think that if it were limited > to AMD platforms alone, then it might well be too narrow, as it would > likely overlap common bits with the Intel work being done. The > existing PPC community is similarly too narrow ... and in fact has > just one project. > > >> Using option 3 would seem to create some problems. If we setup related >> projects for each of the platforms and have projects that are related, >> this seems to be requiring engineers to endorse, monitor and work in >> multiple spaces on related projects. >> > > It means that the folks involved in the project need to cooperate. > > >> In addition, this could require >> competitors to work in a competitor's project area. If the platform >> community sponsored a project, and a neutral/common project then gets >> created, multiple vendors would be able to contribute to a common >> project. >> > > That's in the nature of open development. We're all working on > OpenSolaris here, so the fact that some addresses end in "intel.com" > and others end in "amd.com" isn't actually something I think that the > OGB ought to address. > > A more important issue, I think, is proper system architecture and > design. If, as I think you're asserting, there are common pieces that > should be shared between Intel and AMD platforms, then I would assert > that it's a fundamental _requirement_ that these things are designed > and implemented. At least as a matter of the core software repository > (opensolaris.org), I don't believe it's acceptable to see external > political divisions (of any sort) encoded into the system design. > > >> Case in point... we want to start an AMD IOMMU project. I understand >> that there is already a project started in the Intel space. (I can't >> seem to find it... which is another problem.) If this project was >> already in the Intel project space, it would seem that we would have to >> work in the Intel project space, or deal with the issues of merging two >> project spaces. In addition to this being awkward/frustrating for >> competitors, it would seem to be a hassle for the Sun engineer working >> on any common code. >> > > We've seen the lack of merging before, due to internal political > divisions within Sun, and it's uniformly painful. > > At an architectural level, I would _insist_ that these two projects > work together on common goals. > > I don't actually care how that happens, though. If the high level > issues are hashed out in one of the community groups (device drivers?) > and then a suitable non-partisan joint project is created, that'd be > great. There are probably other ways to divide up the work. > > >> Wouldn't it be preferred to have a project (IOMMU) defined in a more >> neutral space that might be sponsored by multiple communities, like >> device drivers, AMD, Intel and Sun/Sparc? >> > > Yes. That's why I suggested that a platform community would be > useful. > > >> (This seems to be the way that >> the PowerPC community and projects were done.) >> > > No. There's a PPC-only community, and I think that's broken. The > fact that there's a project there is great, but the community is too > narrow to serve that project well. > >
