Joerg Schilling wrote:
I have been told that you cannot introduce new things into OpenSolaris
in case that there is an unasked expert inside Sun.

As others have said, this is not what is intended or desired.  I would
rephrase the intent as

        "you can't introduce new things into OpenSolaris (or change
        existing ones) without first planning for what you want to
        accomplish, communicating your plan to those who have a stake
        in your efforts, and obtaining stakeholder and community
        approval for what you wish to do."

The intent is to encourage projects that impact others to be reviewed
(and improved) by those that are impacted by it.  As we transition from
being Sun-only-Solaris to Community-driven-OpenSolaris, there /will/ be
times where there are Sun-Internal stakeholders that it would be foolish
to ignore.  Hopefully, over time, those people will become active OS.o
participants, and this concern will fade away.  Nevertheless, the intent
is that the right people be involved, no matter where they come from.

  -John

PS: What follows, for those that are still awake, is my understanding
of how changes/additions to OS.o should be handled.  If this differs
significantly from what you have been told, from what you desire, or
what you are doing, we should probably talk about this some more, over
on arc-discuss.


When any change is proposed, the proposer is expected to do
a few "obvious" things:

        Write up a formal proposal that articulates the architectural
        details of what is being planned so that others can determine
        if they will be impacted by this change.

This includes having a set of measurable completion criteria, setting
expectations on new interfaces, describing changes to existing ones,
calling out new or changed dependencies on other components and the
like.  The reason for this is to make sure that everyone is talking
about the exact same thing, and that there is something that other
developers/teams can refer to and rely upon as they build dependencies
on your efforts - both now and in the future.

        Communicate that proposal to interested parties and
        dependent stakeholders.

The OpenSolaris ARC Community is one such interested party, but there
are certainly others - your sponsoring Communities, related Projects,
experts in the areas where you are dabbling, etc.

The ARC Process tries to find a balance between making the project
team do infinite research and communication work and requiring everyone
else to become intimately familier with everything that is being done in
other parts of the meta-community.  In order to make the process flow
smoothly, we assume that sending a proposal to the ARC Community will
reach those who care about reviewing such things.

It therefore is the responsibility of everyone who considers themselves
to be an expert in some area of OpenSolaris to be a part of the OpenSolaris
ARC Community and to review incoming proposals, determine if they are of
interest, and to contact the submitter one-on-one to offer advice and
assistance as needed, not to mention being involved in the review of
such proposals when they are ready for such review.

The corolary of this is that silence = approval, and that ignorance of
what is happening in the ARC community is not an excuse. (you can see
the value of having well written proposals here...)

        Work as needed to refine your proposal, update the architectural
        specs associated with it, gather agreement and consensus that
        your proposed changes are really the best way to achieve your
        goals.

This step may (depending on the scope and impact of the change) include
formal ARC Community interactions and reviews.  It may also require
C-Team interactions, design and code reviews, 1:1 email and/or phone
calls, beer in a local pub, etc :-)

        Go and do the design and implementation work needed to finish
        your project.

If, along the way, you discover additional architectural issues or
artifacts that need to be exposed, do the additional work to discuss,
resolve and approve them as well.

I hope this helps.







_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to