On Thu, Aug 02, 2007 at 12:32:49PM -0400, Brian Gupta wrote: > > to correct that. Projects, however, that aren't fully leverageable on > > current and future OpenSolaris distributions don't belong here. > > > I very much disagree with this. If the goal is to get it running on > OpenSolaris, I think it should be allowed as a project. This goes back to
Please go back and read what I actually wrote. A project to port some piece of software to OpenSolaris is fine with me. So is a project that produces code which also happens to work to some degree on other platforms (indeed, much of the existing codebase came from such projects and is in fact usable elsewhere with little or no effort). A project intending to write some new piece of software for which OpenSolaris is anything less than the primary and first-class target would not be. Let's take two hypothetical examples: 1. The Firefox community decides it's going to rewrite Gecko (again). That community does not list any OpenSolaris distribution among its preferred/officially supported platforms, and is most likely doing the bulk of its development and testing on something else. Any benefits to OpenSolaris users are accidental and arise only from the generic nature of the component itself. This is not an OpenSolaris project, even though the end result will probably be able to execute in an OpenSolaris environment and may provide some benefits to our community. 2. A project team decides to modify Firefox to do away with the needless use of three different threading libraries and instead take advantage of OpenSolaris's native POSIX thread support in libc. This may or may not benefit other platform users and might also make the code more maintainable in general, but the primary purpose is to make the software better for OpenSolaris users by taking advantage of our superior architecture. This is an OpenSolaris project (if a CG wants to sponsor it). And to complete the set from the other side, here are two more examples: 3. A project team at IBM (or anywhere else, for that matter) decides to port DTrace to AIX. Although this team likely would, and certainly should, consult with the DTrace Community Group, theirs is not an OpenSolaris project. It's an AIX project. 4. A project team decides to port HFS+ from MacOS to OpenSolaris. Although the code they start with won't even compile, much less work, with or on any OpenSolaris distribution, it's a perfectly valid OpenSolaris project (if a CG wants to sponsor it): its expected output is intended for integration into an OpenSolaris consolidation and for use primarily on and with OpenSolaris. I think we're in agreement here, at least about case 4. > my idea of having an 'Incubator CG' where new projects can easily be started > and can't easily be classified into existing community groups should start > their life. If they are successful they could have a CG form around them. > e.g. Say I wanted to start a VMWare project, that was dedicated to running > Solaris and OpenSolaris under the various editions of VMWare. (Hopefully > VMWare developers would be invited to participate). Because there is no > existing virtualization community group, it would fall under the incubator > group. As we've noted several times, every Community Group is fully empowered to act in this capacity. Community Group charter boundaries are not rigid, and a project team wishing to do work in an area not perfectly aligned with a single specific Group is welcome to solicit feedback and possible sponsorship from one or more Groups it believes can offer it the expertise and guidance it will need to be successful, even if their work is not strictly within that Group's charter. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
