> Mike et al.,
> Well, perhaps nanofaq, cast into prose. From reading the web and lists I've
> seen, I'm still a little unclear on the actual modus operandi for us ex-
> officio engineers.
> I gather that the community buglist is world-readable--all bugs, save perhaps
> in the still-encumbered components. We can see a sanitized subset of the
> ARC proceedings, with Sun proprietary stuff redacted.
Basically yes. At present, what you can't see is the historical body of
ARC case materials and you can't see the Sun-internal portions of the
existing bug database (fields that may contain proprietary info that we
have not yet cleared or scrubbed). These issues are being actively worked on.
Eventually OpenSolaris developers will have access to all of this stuff.
> The sponsorship process is individual bug driven, so that, for each selected
> bug, we apply, get selected by (perhaps) a different sponsor than for the
> last bug, do our thing, submit the proposed code change to the sponsor. The
> sponsor will surely change if we move across different communities, but
> otherwise might not.
> Sponsor reviews our code, then if s/he approves, s/he does the actual
> putback; we never touch the real gate. Prior to that, sponsor stress tests on
> you guys' test farm. We are assumed to have already tested as far as
> possible on our own farm.
> Putbacks are done in the name of (sponsor, external engineer), so that
> Bonwick knows whose address space to "tear a new address space gap" in, when
> something breaks :-) [cf., "The Quality Death Spiral" by Jeff]
Yes, although we'll also be beating your sponsor to death as well :) This is
because at least in the early going, your sponsor is going to need to help you
do or access things that you need to test before putback that aren't yet
available. One big example is obviously test suites for various things.
> Assuming I have this right, does this procedure remain the same for everyone?
> It seems fine for an occasional contributor, but I can image an "Outside
> Jack" feeling a bit frustrated by the protocol.
> If the entity being sponsored is just an engineer, and not the ordered pair
> (engineer, specific bug), then within that community, Jack could work with
> the same sponsor for all his code, and the sponsor would get a personal feel
> for Jack's work. This I think would expedite the mechanics and improve
> product quality as well.
> I indeed appreciate the tremendous amount of work that has gone in to washing
> out the encumbrances from the code, but I can still imagine situations where
> an external engineer might need to covered by an NDA, even if this runs a bit
> counter to the guiding spirit of Open.
> How close am I here to what the current plan envisions?
The procedures will be the same for everyone, but certainly as you suggest we
want people to develop relationships with their sponsors and with the leaders
of various communities within OpenSolaris (or eventually become leaders
themselves) and as you say we expect these things to expedite work once a
positive reputation and track record are established. This is no different
from how things have worked within Sun for all of Solaris's history. To
that end, just as we do within Sun, your sponsor will be assigned in some
logical fashion based on past history and/or what area you're working in.
I also want to emphasize that the proxy mechanism itself is temporary: this
is how we can facilitate actual Open development occurring in this nascent
state where external developers cannot actually get access to the underlying
gate, the test suites, the docs, the ARC and CRT processes, and all the other
stuff. As shown on the opensolaris.org roadmap, these will roll out over the
rest of this year. So as more pieces roll out, the proxy part will become
less and less necessary and eventually external developers should be able to
do, securely over the web, the same steps we Sun developers have done, modulo
any adjustments to the process the community as a whole decides to undertake.
With respect to NDAs, etc. that is also being worked on. As part of the
initial release of opensolaris code, the small amount of remaining code in
Solaris that was encumbered was segregated out so we don't intermingle them.
The CAB and OpenSolaris team will, going forward, be figuring out the processes
for how we can either get rid of those NDA things or get external developers
who need access to those things the ability to work on them.
Mike Shapiro, Solaris Kernel Development.