On Tue, Jun 05, 2007 at 02:38:21PM -0700, Garrett D'Amore wrote:

> I believe that even OpenSolaris.org will need at some point, to run 
> cases that are, for a time at least, closed.  (Or at least, only open to 
> a limited selection of individuals, not necessarily based upon their 
> place of employment.)  I think some thought should be given to that.

What is incomplete about Jim's suggestion?  If a contributor wants to
make changes to its own closed consolidations, it's free to construct
whatever infrastructure it likes to review those changes.  Since the
changes are not visible outside that constributor, and the case
materials are neither available nor establish precedent outside it,
why should anyone else care?

Sun might want (it certainly does not need) to run closed cases; we
have nothing to say about that.  But I would expect an OpenSolaris
C-team to disregard any invisible, closed review, whether made within
Sun or elsewhere, when determining whether a project is ready for
integration into an open consolidation.  That is, if your project is
Sun-confidential, it is Sun-confidential all the way through and past
integration, and you are therefore targetting a Solaris-specific
consolidation that is irrelevant to this discussion.  Or, if your
project is targetting an OpenSolaris consolidation, you are obliged to
engage in open review from a sufficiently early point that everyone
has the opportunity to participate and to meaningfully advise your
project team.

Consider the alternative: a MegaloCorp project team engages in
confidential review early in the life of its work, and does its work
in secrecy on the basis of that review's results.  At a later time,
when the project is complete and has been approved within MegaloCorp's
processes, the team is new ready (based on whatever criteria it or
MegaloCorp chooses) to share the code with the rest of us.  Prior to
integration, we require an open architectural review of what is, for
all intents and purposes, a completed work.

There are several extremely problematic aspects that will arise at
this time:

    - MegaloCorp is almost certainly pressuring its project team to
    get this work integrated ASAP.

    - Issues may be uncovered during open review that were not
    addressed during previous reviews (perhaps MegaloCorp has shoddy
    review processes, or even none at all).

    - If the ARC consists primarily of other MegaloCorp employees, it
    may not be receptive to input from others if that input would
    require the project to be delayed.

    - During the period in which this work was conducted secretly,
    other project teams may have created duplicate or conflicting
    architectural constructs.  Some may even have integrated.  What
    happens to the MegaloCorp project then?

It is certainly true that some project teams will simply recognise
that dealing with these problems is part of the cost of operating in
secret.  Those do not worry me.  What do worry me are the project
teams who will try to game the system and apply undue influence to
meet their own deadlines.  And as long as you allow this mode of
operation, there will be those teams.

-- 
Keith M Wesolowski              "Sir, we're surrounded!" 
FishWorks                       "Excellent; we can attack in any direction!" 

Reply via email to