On Thu 03/16/06 at 11:30 AM, [EMAIL PROTECTED] wrote:
> 
>   I believe this proposal needs to provide further contrasts against
>   existing communities and projects to make aspects more clear.
>   (As a nit, the bare word "solaris" is not an appropriate part for a
>   community name.  I'm also not sure that "opensolaris" is better, as
>   there are many participating technologies in OpenSolaris as a whole
>   that could reasonably claim to have meaningful "internals".)
> 
>   1.  What is the relationship between this community and existing,
>       demonstrably technical communities, like the networking, zones,
>       and zfs communities?

This community would be for issues that span existing communities or which
do not have a dedicated community. 

>   2.  What is the relationship between this community and the existing ON
>       (Nevada) community?  Why is that alias, or a second alias (or
>       project) not appropriate for hosting this content?  (Why not
>       [EMAIL PROTECTED])

The Nevada community seems to be shooting for a C-team kind of function,
while we are trying to get to more of an I-team level.  Also, we want to
pull in historical information to help explain how we got to this point,
which would seem inappropriate for a Nevada-specific group.

on-internals is probably a better name.  It certainly captures the intended
scope of the community better than solaris-internals.  As I noted in my
reply to Alan, I was originally put off by the inside-baseball nature of
the ON acronym.  I've spent some more time poking around, and it seems that
ON is used commonly enough that it would be safe to adopt here.

>   3.  What is the relationship between this community and the existing
>       opensolaris-code and opensolaris-rfe aliases (which are discussing
>       technical topics regarding ON components)?

opensolaris-code is just a mailing list and provides no mechanism for
hosting documents and its charter ("OpenSolaris Code General Discussion")
is overly broad.  There are occasionally technical discussions about OS
internals, but the topics range from how to build OpenSolaris to why an
applications builds with g++ but not SunStudio to "are there any .c to .pl
converters for OpenSolaris".

The broadness of the charter invites topics which don't even fit the
charter (e.g. "Why is Sun dhcp unusable?")

opensolaris-rfe is not a particularly technical list.  The topics tend to
be vaguely-specified statements about some user-visible feature that is
missing or just misunderstood.

        "I'm personally bored with having to manually change shell just to
        get command line editing working."

        "Would it be possible when creating a zfs file system to be able to
        set various properties in the one command rather than having to do
        two or three commands to get the same result?"

        "Need support for PL2303 USB to serial adaptor"

        "A tool needed (should be seperate thread, but I am lazy..) is a
        gui tool for managing packages."

>   4.  We're examining communities commenting on new community proposals
>       and community-to-project demotion processes on cab-discuss; no
>       aspect of that discussion really suggests that one community
>       should propose its existence based on the subsumption of others.
>       I certainly don't think that that's a suitable mechanism for the
>       alleged proliferation problem.

This group does not depend on the subsumption of others.  That was offered
as a potential side effect.

Nils
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to