Valerie Bubb Fenwick writes: > It had always been my impression from when we started the sponsorship > process that it was a "temporary" stop-gap measure until people could > do their own putbacks. Rich mentions above that we may not want to let > any unknown person off the street do an integration from the get-go, > like until they've had a few proven good integrations. > > We have no such process for internal employees, but Rich noted that > we don't really need one because is an internal employee does something > malicious to the gate - they will have repercussions with their management. > > No such luck if that person doesn't work for Sun.
I don't think that's a real problem. The penalty is effectively the same: you get locked out of the gate (commit privileges revoked) and your changes are reverted by the gatekeeper. If there's a legal issue involved, well, things could be far worse, depending on who the injured parties are, and how they feel about pursuing the issue. In any event, I don't see a distinction that's worthwhile here. The paycheck issue is a red herring. > I hadn't thought about that, but can see how we may want to limit who > can commit changes even once everything is external. JBeck or others - > is there a new plan on this? or should we just start brainstorming one? We already have exactly this in the existing web site. You have to be explicitly granted commit privileges -- by being a "project leader" or by affiliating *and* asking one of those leaders to set your commit-allowed flag. All that's really needed is some (perhaps informal) process for deciding who gets his commit bit set. I'd argue for (a) requiring at least affiliation in order to file an RTI and (b) setting the commit bit on any user who has an approved RTI. Problem solved. ;-} -- 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
