Publishing code reviews
Peter B. Kessler
Peter.Kessler at Sun.COM
Thu Oct 11 17:44:03 PDT 2007
Tim O'Brien wrote:
> On 10/11/07, *Peter B. Kessler* <Peter.Kessler at sun.com
> <mailto:Peter.Kessler at sun.com>> wrote:
> Tim O'Brien wrote:
> > On 10/11/07, *Mark Reinhold* <mr at sun.com <mailto:mr at sun.com>
> <mailto:mr at sun.com <mailto:mr at sun.com>>> wrote:
> > > Would we need to somehow filter out the webrevs which
> > > contain closed sources?
> > Yes. That's a Sun-internal problem, though, so let's discuss it
> > internally.
> > That's interesting, what sort of code is closed? Is there ever
> > to be a case where a webrev contains certain sections that are public
> > and certain sections that are private? since you mentioned it on a
> > public list, could you give us a sense of what the public is
> Think of the code we can't release because of the encumberances.
> If we have to make changes in that code, we need to get reviews,
> but we can't ask the community for help with those reviews.
> Clearly the less code we have that we can't put in the open the
> better. But as long as that set is non-empty, it's something we
> have to deal with, internally.
> Ok, so just to clear it up for the non-Sun folks this would be things
> like the font rasterization stuff that is still encumbered. Ideally
> the encumbered code shrinks over time, and there's less of a chance of a
> webrev spanning encumbered and non-encumbered code. I'd assume that
> you'll continue to use the internal review systems just for those code
Right. The trick is having a process in place that keeps the
webrevs for the internal stuff separate from the open webrevs.
I think we'd all much rather everything was open, but it isn't.
It's all still exciting and new to be discussing our process
stuff out in the open, and this probably won't be the only
time we'll confuse you with the hoops we have to jump through.
More information about the discuss