Garrett D'Amore writes: > Perhaps what I meant didn't come across clearly. What I'm saying is > that, at least in the near term, I think OpenSolaris should basically > give a "grant" to PSARC to authorize cases. It may make sense to > provide similar grants (especially LSARC, but maybe others besides.) > > I don't necessarily intend this situation to be permanent.... eventually > OpenSolaris will need to build its own ARCs for its own needs, but as a > transition measure, it seems reasonable.
Ah, ok. Yes, that can work, but I think it creates some interesting new problems that we really don't know how to solve. The ARC (load-balanced into separate groups, but operating as one body) is intentionally a single group across Sun, so that it can be in a position to review *everything*. What this split ultimately proposes is that we end up over time with multiple independent ARCs that somehow have to cooperate for the good of all. While it's true that we've effectively had this situation for some time now -- ARC reviews 'ignoring' or 'grandfathering' third party products are a good example -- it's not something that has historically led to well-integrated products. Alan Coopersmith writes: > The deadline was intended to apply to when the decision was made, not > when it was published. Old decisions could still be published after > that date - you just won't be able to say "You have to comply with the > precedent set in 1994/XXX" until you go publish 1994/XXX so the open > project teams can see what it says. Got it; thanks. Keith M Wesolowski writes: > 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 What's incomplete about my suggestion is that I (somewhat intentionally) don't deal with the problem of coordinating "really big" projects that touch on both closed and open bits. Reviewing just the open component of those projects will likely lead to much lower quality reviews and substantial difficulty. I realize that this is a natural outcome of going open source, and that it's to some extent just plain goodness for OpenSolaris itself (applying some force to make more things open), I think there'll also be a non-trivial internal Sun problem with it. > 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. Indeed. It's not acceptable as an open process. However, after switching s/MegaloCorp/Sun/g, there are practical problems to consider -- Sun can't just sink because OpenSolaris tells it to. I don't know what the balance might be, but that doesn't seem like a viable answer. So, while we're forcing Sun management into openness, what's a "Fishwork?" :-/ Alan Coopersmith writes: > I don't think the OGB needs to determine exactly who the ARC is or how it's > run - by delegating that to the ARC community, I was leaving that community > the freedom to, for now, create a committee from it's current contributors > and core contributors that has a membership list very much like the current > PSARC, and which meets at any time the PSARC has scheduled an open meeting, > if that's the plan the ARC sees best for now - or to decide when neccessary > in the future to diverge the membership (by adding non-Sun employees) or > creating multiple ARC committess (Open Platform ARC & Open Layered ARC > perhaps). OK; I was responding to the suggestion that PSARC becomes "the" ARC. As long as that doesn't become part of the OGB policy, and the mechanics are deferred to the community, +1 from me. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
