Richard Lowe writes: > James Carlson <james.d.carlson at Sun.COM> writes: > > On 14, one of the things not listed is that the C-team needs to start > > acting in the open, at least with respect to RTI Advocates and review > > of projects involving open source. Without this, at least part of the > > process related to large projects (C-team review) won't be on > > equitable footing for external committers. > > I've been harping on about this for a long long time now, and have > essentially given up on complaining about it. > > My view, at this point, is that it isn't really worth mentioning in > the vast majority of contexts (if any). If you want to, go for it, > but not in a way that raises expectations regarding it eventually > being done properly, I, at least, have no faith it ever will.
I don't think it's really as bad as all that, though I can see how it's frustrating from the outside. For an analogy, just think about how remote and implausible a live Mercurial gate seemed a year ago, and look how close we are now. ;-} Unlike the ARC, which "just" reviews high-level project plans, the C-team fills multiple roles, and I think this adds a good bit of complexity. There are some things they're doing that need to be treated in the same way as ARC cases (particularly the project reviews). There are others that look like community governance issues (RTI Advocate lists). And still others that are internal issues (Sun's own release schedules). I know they've had many discussions about how to do this, but I haven't been a part of them, so I don't know the current status. Personally, I'd like to seem them just take the gamble in making it all open and then cleaning up the mistakes afterwards, but I'm not in charge. One bit of good news is that John Beck is tech lead for Nevada ON, and is very interested in opening things up. Back to the document: the key issue here to me is that having C-team project reviews in the open (just like ARC reviews are open) is crucial to having an open development process that allows not just simple bug fixes (which don't require C-team review) but larger projects as well. Having non-Sun advocates can perhaps lag that, because it's a separate issue, but blocking projects on Sun employees acting as proxies is an incomplete answer. There's a lot of 'stuff' buried here in terms of completing the task. The test and documentation "resources" -- essentially a detailed management issue -- are checked by the C-team. What does that mean for open projects? Projects are tracked through an elaborate "Dashboard" application that nobody (as far as I know) has thought about opening up, but that project leaders _need_ to use. Where does that leave projects that have only non-Sun participants? And then there's the whole legal review issue ... -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
