[ogb-discuss] Creating a place for AMD-related work (fwd)

[Eric Boutilier]

---------- Forwarded message ----------
Date: Tue, 16 Oct 2007 09:51:37 -0500
From: Eric Boutilier <Eric.Boutilier at Sun.COM>
Cc: "Herman, George" <George.Herman at amd.com>,
     James Carlson <James.D.Carlson at Sun.COM>,
     "Ostrovsky, Boris" <Boris.Ostrovsky at amd.com>
Subject: Re: [ogb-discuss] Creating a place for AMD-related work

Interesting! Pretty good arguments both ways, IMO.

At this point the best thing for Boris and George to do is
pursue an official community proposal, right?

I note also that whether it flies or not, the decisions reached
during the vetting of the proposal will set really useful precedents.

Eric


Herman, George wrote:
> 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.) OGB may not have to
> arbitrate these kinds of issues, but making the right decision on how
> communities and projects are initially created can help minimize
> conflict.
> 
> 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. 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.
> 
> 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.
> 
> 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? (This seems to be the way that
> the PowerPC community and projects were done.)
> 
> -George
> 
> 
> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at sun.com]
> Sent: Tuesday, October 16, 2007 6:43 AM
> To: Ostrovsky, Boris
> Cc: ogb-discuss at opensolaris.org; Herman, George
> Subject: Re: [ogb-discuss] Creating a place for AMD-related work
> 
> Ostrovsky, Boris writes:
>> What is the process for creating such an umbrella project? Or, rather,
>> how can a project create a sub-project? According to
>> http://www.opensolaris.org/os/community/ogb/policies/project-
>> instantiation.txt
>> a project can only be started by a community (or communities).
> 
> I would just start the umbrella project in the community by posting a
> description of the overall project (as outlined in that document) to
> the community group mailing list, gathering the votes to endorse the
> project, and then contacting Eric Boutilier to set up the
> opensolaris.org structures needed for the project.
> 
> There's no need to get fancy about this. If a project can
> self-organize into smaller units for its own purposes, then more power
> to it. The web site infrastructure already allows you to set up
> whatever pages and source code management resources you need, and Eric
> can set up multiple mailing lists (if you need that), so I think
> you're all set.
> 
>> There is also a question of developing features that are common to
>> multiple platforms. If different platforms are interested in similar
>> functionality (but with separate architecture-specific low-level
>> drivers), how would creating common code be coordinated between
>> platform-based projects? With platform communities, there is a project
>> co-sponsored by them, with a single source tree.
> 
> There are multiple ways to do this, but I don't think the OGB is the
> best arbiter of those resources.
> 
> What you need to get is common agreement among the project teams that
> creating the common code (or framework) is the right thing to do. You
> can do that by talking with the other project teams, or by getting the
> community group to endorse the approach (and thus require it out of
> each of its endorsed projects), or by creating such a framework in
> your own project and then getting ARC approval for it.
> 
> The OGB isn't involved in that process unless there's some unresolved
> (and unresolvable) conflict in the community group, or there are
> conflicts between community groups. I wouldn't suggest using that
> path, as the OGB's powers here are administrative rather than
> technical, and we essentially get to terminate the bits that aren't
> working.
>