"C-Team
Consolidation Team: the release team managing a specific Consolidation.
"
So, before I start with the PSARC case integraition policy -
1. ON C-Team - who are these people ?
Since "managing a specific Consolidation" isn't really useful: this is the
group of people that review projects prior to integration to ON. The
mailing list (see below) has about sixty subscribers. About a dozen people
call in regularly to meetings, which happen once a week.
There is a smaller group of people called the core team. These five
people are the only full-time members of the c-team; everybody else is in
for (nominally) four hours a week.
Up 'til now, these are all Sun employees. We need a mechanism to include
folks from outside Sun; I'll drive that, if I can't find anybody else
already working on it.
2. How OpenSolaris community gets to know them ?
I blogged about the core team a couple of years ago:
http://blogs.sun.com/mjnelson/date/20050614
That membership is now out of date as follows:
- Assistant Tech Lead / Triage Lead: Nick Todd succeeds Peter Dennis
- Gatekeeper: David Marker succeeds Danek Duvall
- Program Manager: Miguel Ulloa succeeds Kelli Dupee
- Assistant Gatekeeper: TBD to succeed David Marker, who previously
succeeded Natalya Reznik
We're in the (taking way too long) process of moving our aliases to
OpenSolaris (see below).
3. How many people are there ?
(repeating from above) About sixty on the alias. Maybe a dozen or two
participate regularly, and five are full time.
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?"
5. Who can choose them ?
Generally, the core team program manager (Miguel) will make sure the new
member knows what we expect of them, and add them to the team alias.
Sometimes we get people that come to us, sometimes we solicit people based
on our need for their expertise.
I know of no rigorous selection process, though historically there might
have been something more formal.
6. What it takes to get into C-Team ?
Experience developing Solaris.
Familiarity with SAC processes.
Desire for Solaris to continue evolving without sacrificing quality.
Commitment to review incoming projects promptly and thoroughly, to the
best of one's ability, and to share feedback in a respectful, positive
way.
7. What kind of decisions C-Team makes or what kind of responsibility
does it have ?
We grant final approval for projects integrating to ON. We're responsible
for making sure those projects are well implemented and tested.
Such approval is generally clear by consensus following a review, and is
granted conditionally on completion of a list of clear action items. It
is left to the core team to judge when those AIs are complete, and the
Tech Lead to express final approval via acceptance of a project's Request
To Integrate (RTI).
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.
While we're at it, it's also time for our gate notification alias to be
moved to OpenSolaris and split up.
After discussion with Steve Lau, Nick Todd, and Danek Duvall, we propose
the following changes:
1. Rename OpenSolaris ON Community to "OSNet"
This change is actually an artifact of the community/project shared
namespace on os.o. It's a confusing annoyance, but really this
community should be where the on-gate project lives, and that project
is where the repositories that make up the consolidation should live.
2. Rename OpenSolaris ONNV Project to "ON"
Same motivation as above.
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.
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.)
5. Creat the on-notify mailing list
This is to replace the internal-to-Sun [EMAIL PROTECTED] and
[EMAIL PROTECTED] This list is not for discussion,
but rather for notification of changes to the on-gate repository.
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.
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?
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.
I'm sure I left some items out.
Thoughts?
--Mark
_______________________________________________
opensolaris-discuss mailing list
[email protected]
