Thanks, Mark... A few notes and lots of trimming :)
On Mon, 2 Apr 2007, Mark J. Nelson wrote:
[...]
4. How the members of the C-Team are being [s]elected ?
Selected.
An excellent question, and one that cries out for both documentation and
change. Traditionally, it's a volunteer duty, and we have striven for a
broad range of subject matter expertise. There have been few (if any)
additions in the last couple of years, and as this release rolls on, that
will need to change.
When I joined the c-team, I did so by sending a note to the program manager
and saying "I want to join, what do I do?"
There is more process involved for selection of core members, and much
more management control (as these are full time positions, your manager
needs to accept that you won't be doing any (or much) work on your groups
projects for the time you serve as a core team member).
[...]
8. What kind of interaction with the community should C-Team have ?
Heh. Clearly "more than it has," and also "that's changing."
How is it changing? First off, the c-team and core team have traditionally
been release-oriented.
There's not an "on c-team" that's active over multiple releases. Instead, there's an
"on81-cteam,"
"on10-cteam," and "onnv-cteam," each active over the lifetime of the
corresponding release. There's
also an "on-su-cteam," which coordinates the ON Consolidation for the Solaris
Update releases.
But with OpenSolaris, there should appropriately be an "on-cteam," watching
over the consolidation.
And that team probably won't care about the Nevada release, at least not
directly, because that's a Sun
internal consideration.
I'm not sure I understand this motivation or agree with it (well, I don't agree
with
it, but perhaps I don't understand it ;)
ONNV is currently what makes up the bulk of OpenSolaris. Yes, there are many
other
projects going on out there, but they aren't integrated into ON (and some have
no
plans to, either) so should not affect the name of this group.
And, as you say, there is no board to oversee all releases - and as you know,
Solaris 10 is still active in the form of Updates. So, calling this simply
"ON C-team" implies a much more broad charter than this team actually has.
Nevada, the codename for the next release of Solaris, may be an internal
"artifact"
of Sun, but it is our main driving force as a c-team. Also, other distributions
of OPenSolaris are not affected by this, as they are completely doing their own
thing.
[...]
3. Rename Steve's onnv-gate repository to on-gate
...and put it under the ON Project. This shouldn't be tied to Nevada;
when it's time to worry about releasing Nevada, then the onnv-gate (or
maybe even on11-gate) repository should be created as a fork of
on-gate.
Why should we hide our internal forking & gate shifting from the outside?
4. Create the on-cteam mailing list
This list will be for c-team project reviews of all open projects,
which is pretty much anything from inside or outside of Sun. (What
might constitute a closed project, unsuitable for this alias, is not
this discussion.)
Again, I think this implies a charter much more broad than we have.
6. Create the on-announce mailing list
This is to replace the internal-to-Sun [EMAIL PROTECTED] alias. It's not
for discussion, but rather for stuff like flag day and heads up
notices, which should generally get more careful attention than putback
notices.
This is a fantastic idea! As you know, the current "on-all" alias is used
for covering projects & flag days related to ALL currently active releases.
7. I haven't figured out what will be needed in the way of an on-discuss
mailing list. We traditionally have not had such a beast inside Sun,
though on-all has occasionally been [ab]used in this fashion.
Anybody got an opinion on this?
I think there is need for one. We could send announcements to on-announce &
set reply-to's to on-discuss.
8. Internal to Sun, we'll need to scrap onnv-cteam, and replace it with
the aforementioned on-cteam. I don't yet know if we'll also need an
internal-only alias; my preference and hope is "no," but there will be
some projects and/or business units that will object to the
preannouncement of some of their work.
there are still projects that for legal & US export reasons will need to be
reviewed & discussed privately. There aren't many, and we've all been pushing
this to get as close to zero as possible, but there will still be some.
I think we can follow PSARC's lead on this and try to do most discussion on
the external alias & save confidential/legal related issues for the internal
alias. PSARC has some open meetings as well, but not all, for this same reason.
That's just my 2 cents :)
Valerie
--
Valerie Bubb, http://blogs.sun.com/bubbva
Solaris Security Technologies, Developer, Sun Microsystems, Inc.
17 Network Circle, Menlo Park, CA, 94025. 650-786-0461
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
