Keith M Wesolowski wrote:
> 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.
>>
>
>
In answer to the comments you make below: that is why I think there has
to be an allowance for closed (not necessarily Sun internal, but perhaps
with community ARC members operating under a limited NDA, maybe even
just a gentleman's agreement not to blab) review in the community.
I.e. it should be possible to get some of the ARC input, without
advertising the details to the _rest_ of the world.
I hope we never need such a facility, but I'm fairly sure that we will
either need one, or in the absence of one, we'll see companies take the
MegaloCorp approach you describe below.
-- Garrett
> 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.
>
>
