[ogb-discuss] OGB/2007/002 Community and Project Reorganisation

Eric Boutilier Eric.Boutilier at Sun.COM
Mon Apr 23 07:03:41 PDT 2007


On Sun, 22 Apr 2007, Keith M Wesolowski wrote:
> On Thu, Apr 19, 2007 at 10:47:00AM -0700, Stephen Lau wrote:
>
>> There is confusion as to what is a community vs. a project on
>> OpenSolaris.org.  Some of this is due to grandfathered communities who
>> were instantiated when the website lacked project support.  In today's
>
> Actually, the confusion may well be a product of previous incarnations
> of the tools, but it's not confusion over what's on the web site or
> how it appears to visitors.  Rather, the contents are just artifacts
> of the OpenSolaris community's actual organisation as specified in the
> Constitution, and that organisation is what's in chaos.
>
> So I might rephrase this as "The current sets of Community Groups and
> Projects reflect historical inconsistency and have resulted as much
> from infrastructure constraints as from strategic intent."  And in
> general, limit references to opensolaris.org to those clauses in which
> we refer specifically to hosting artifacts, not governance or
> organisation.
>
>> governance, communities are broad umbrella interest groups which have
>> representation in OpenSolaris.org governance whereas projects are focused
>> around achieving a specific goal or objective and do not have governance
>> representation.
>
> Community Groups don't actually have "governance representation"
> either - the Core Contributors govern the Groups and elect the OGB.
> Is the intent here to align the existing organisation with the one
> specified by the Constitution, or to ameliorate a perceived pattern of
> individual disenfranchisement (or both)?
>
>> 3 Proposed Community Reorganisation
>> 	Sections 3.1 through 3.5 are a summarised explanation of the proposed
>> 	changes, with Section 3.6 being the proposed list of communities.
>>
>> 	3.1  Create new communities:
>> 		- Distributions
>> 			- for OpenSolaris distributions to affiliate with
>> 			  and get governance representation
>> 		- Filesystems
>> 		- Freeware
>> 		- Virtualization
>> 		- Performance & Observability (merged, see 3.5)
>> 		- Ports
>> 		- Marketing & User Groups (merged, see 3.5)
>
> One thing I'd like to see is a strategy for merging these Groups
> and/or creating new ones.  In the case of merged Groups, it seems
> reasonable that the OGB could help the existing Core Contributors draw
> up a merger agreement.  Would we solicit founding members of each new
> Group, and if so how?  There's plenty of leeway in Sec. 7.4 for any of
> a number of schemes; it would be useful to describe our strategy here.
>
> Also, some specific notes:
>
> Would Filesystems be the merged set of UFS. NFS. and ZFS?  I won't
> name names, but there are a couple of dubious Core Contributors among
> that set; what, if anything, should be done about that moving forward?
>
> We should really find a better name than Freeware, which is not
> necessarily accurate (the term is usually used to refer to price
> rather than freedom[0[) and would not in any case be unique since the
> entire community is built around Free Software.  I might suggest a
> more ambitious name such as External Software Integration.
>
>> 	3.3  Re-classify the following communities as projects:
> ...
>> 		- 'GNU Solaris' endorsed by Freeware
> ...
>> 		- 'Solaris Volume Manager' renamed to 'Volume Manager' and
>> 			endorsed by Storage
>
> One of the few agreements that's arisen from the naming thread is that
> Solaris doesn't belong in any project's name (and sec. 7.4's
> requirement #2 prohibits its use in a Community Group name).  As a
> Group name, "GNU Solaris" falls doubly afoul of 7.4, but even as a
> project it would need a new name.
>
> Is it worth splitting project naming (and renaming) into a separate
> proposal (possibly into 2007/001 or an entirely new one)?  It seems
> that both 2007/001 and this proposal actually depend on a reasonable
> project naming policy.  I'm willing to put some effort into a
> compromise proposal if that would be useful; at the very least, it
> would help to have a policy precluding the use of 'Solaris' and
> 'OpenSolaris' in any project name.
>
> Would we expect that these Community Groups form a merger and
> reclassification agreement with one or more of their endorsing
> Community Groups transferring their grants (or not, as the parties see
> fit)?  Would we require the project teams to re-publish (or, in some
> cases, publish) the information required by OGB/2007/001?
>
>> 	3.6 Final list of reorganised communities:
>
> I've reordered this list a bit to better organise my thoughts on it,
> but I haven't removed any.
>
>> 		Academic & Research
>> 		High Performance Computing
>
> These would seem to have a good deal in common.  Another merger
> opportunity?  If nothing else, I'd like to better understand what
> makes research itself a unique element, as opposed to Groups simply
> sponsoring research in their respective areas of expertise.
>
>> 		Distributions
>> 		Installation & Packaging
>
> Installation (exclusively) and packaging (primarily - I'm aware of the
> exceptions such as Zones) are distribution issues.  Would it make more
> sense to merge these into a Productisation Community Group?
>
>> 		Filesystems
>> 		Storage
>
> I have to confess to some serious concerns about the Storage Community
> Group; its content (and some of what I've seen in recent press
> releases) looks more like Sun advertising than an active engineering
> community (and of the 25 blocks in the architectural block diagram, at
> least 7 don't appear to be a part of, or targetting, OpenSolaris).  It
> also claims to be endorsing YANFS, which is not properly an
> OpenSolaris project at all.  We should probably address those specific
> issues separately, but I do wonder whether a filesystems community
> group and a more active and involved storage group shouldn't really be
> one and the same.
>
>> 		Approachability
>> 		Immigrants
>
> These seem to have considerable overlap.
>
>> 		Architecture Process and Tools
>> 		OS/Net (ON)
>
> It's reasonable to leave these alone for now, but recognise explicitly
> that neither should be considered to have established a precedent, and
> either or both are likely to be reorganised by a subsequent act.
>
>> 		Appliances
>> 		Desktop
>> 		Device Drivers
>> 		Documentation
>> 		Freeware
>> 		Games
>> 		Internationalization & Localization
>> 		Laptop
>> 		Marketing & User Groups
>> 		Networking
>> 		OpenSolaris Governing Board (OGB)
>> 		Performance & Observability
>> 		Ports
>> 		Printing
>> 		Security
>> 		System Administration & Management
>> 		Testing
>> 		Tools
>> 		Virtualization
>
>> 	4.1 Rename existing projects
>> 		The impetus for renaming certain communities comes from
>
> I assume you mean 'renaming certain projects' here since that's what
> it does.
>
>> 		- 'OpenSolaris Busybox' becomes Busybox
>> 		- 'New Design of 4over6 Mechanism Based on OpenSolaris'
>> 			becomes '4over6 Mechanism Redesign'
>> 		- 'Enable/Enhance Solaris Support for Intel Platform' becomes
>> 			'Intel Project - Enhancing Solaris support'
>> 		- 'Enhance the support of USB webcams' becomes 'USB Webcams'
>> 		- 'OpenSolaris Ports Collection' becomes 'Ports Collection'
>
> This seems confusing with respect to the Ports Community Group, which
> has nothing to do with it. I know this is a conflict between two
> established uses of the word;


Especially with respect to end users, I think. That is when
the word "Ports" is used in an open-source community context,
most think of repositories of F/OSS packages as made famous
by the FreeBSD/NetBSD/OpenBSD communities.

And as you point out above, there's controversy over the word
Freeware in an open-source context.

So it's tempting to want to be compatible with the *BSD sense
for the use of the word "Ports", but then how do we solve for
the architecture porting community name?

> could we ask the project team to suggest a clearer name?

Are you suggesting pulling in the leaders and/or contributors
of the various active OpenSolaris freeware porting efforts
(SFW, CCD, JDS, and X?) and architecture porting efforts
(PowerPC and S390?) and asking them to comment?

Sounds like a good idea.

Eric


>> 		- 'OpenSolaris support for the QEMU processor...' becomes
>> 			'QEMU Processor emulator -- host and guest'
>> 		- 'Support gcc4/GCCfss in Solaris' becomes
>> 			'gcc4/GCCfss Support in Solaris'
>
> We should drop the reference to Solaris.
>
>> 	4.2 Merge existing projects
>> 		- 'Solaris PowerPC Port' is merged with the new PowerPC project
>> 			(formed from the previous PowerPC Community)
>> 		- 'SMF Documentation' is folded into the smf(5) project
>
> ...
>
>> 	CIFS client for Solaris
>> 		- Filesystems, Networking, Immigrants, Storage, Appliances
>
> Needs renaming.
>
>> 	Caiman, Solaris Install Revisited
>> 		- Installation & Packaging, Approachability,
>> 		  System Administration & Management
>
> Needs renaming.
>
>> 	Ethernet bridge module for Solaris
>> 		- Networking
>
> Likewise.
>
>> 	Fuse on Solaris
>> 		- Filesystems, Storage, System Administration & Management
>
> Likewise.
>
>> 	gcc4/GCCfss Support in Solaris
>> 		- Tools
>
> Likewise, as noted previously.
>
>> 	GNU Solaris
>> 		- Immigrants, Freeware
>
> Likewise, as noted previously.
>
>> 	Intel Project - Enable/enhance Solaris support for Intel Platforms
>> 		- OS/Net, High Performance Computing, Device Drivers,
>> 		  Laptop, Performance & Observability, Ports
>
> Likewise.
>
>> 	Muskoka: An open repository for OpenSolaris technical content
>> 		- OS/Net, Documentation
>
> Likewise.
>
>> 	Network Storage
>> 		- Networking, Storage
>> 	SFW
>> 		- Freeware
>
> We have here an inconsistency with ON; this should be explicitly
> excluded from setting any sort of precedent until we work it out
> separately.
>
>> 	Object Storage Device (OSD) support for Solaris
>> 		- Storage
>
> Needs renaming.
>
>> 	OpenSolaris Content Project
>> 		- Documentation
>> 	OpenSolaris Security Audit
>> 		- Security
>
> Likewise.
>
>> 	Printable Many Page Solaris Manuals
>> 		- Documentation
>
> Likewise.
>
>> 	smf(5)
>> 		- System Administration & Management, Approachability
>> 	SMF Documentation
>> 		- System Administration & Management, Documentation
>
> You merged these two projects in 4.2.
>
>> 	Shell: bourne shell, korn shell, C shell, etc.
>> 		- System Administration & Management, Immigrants
>
> It's not clear that this is really a project.  It actually seems more
> like a Community Group, in that it would kick off an indefinite series
> of projects with specific goals.  This requires more investigation.
>
>> 	Solaris iSCSI Target
>> 		- Storage, Networking
>
> Needs renaming.
>
>> 	Sun StorageTek Availability Suite
>> 		- Storage
>
> May need renaming.  Requires investigation in general.
>
>> 	Tamarack: Removable Media Enhancements in Solaris
>> 		- Approachability, Desktop
>
> Needs renaming.
>
> [0] http://www.google.com/search?hl=en&defl=en&q=define:Freeware&sa=X&oi=glossary_definition&ct=title, and especially
>    http://en.wikipedia.org/wiki/Freeware
>
> -- 
> Keith M Wesolowski		"Sir, we're surrounded!"
> FishWorks			"Excellent; we can attack in any direction!"
> _______________________________________________
> ogb-discuss mailing list
> ogb-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/ogb-discuss
>



More information about the ogb-discuss mailing list