Karl Fogel wrote:
> First, some context:
>
> This mail is a followup to a formerly private thread among the
> Subversion full committers. Below, I quote a bit of context from that
> thread, but I think the original poster won't mind, as there's nothing
> really private about it.
>
> C. Michael Pilato wrote:
>> Karl, I posted this to s-f-c because we always post discussions
>> about commit access to s-f-c. Maybe this is different because we
>> aren't evaluating someone's skillset, though -- I dunno.
>
> Exactly what I was getting at, yes. Let me make the point explicit:
>
> The reason most commit access discussions happen on s-f-c is not
> because they are about commit access per se. Rather, it's because
> they often (but not always) involve speaking frankly with each other
> about someone's skills, and that obviously can't be public.
>
> But note the "not always" above! When the discussion doesn't involve
> any sensitive stuff, then it can and should be on dev@.
>
> The "Elego tree conflicts work" conversation was really about "What
> should our branch policy be?" not "How skilled are Elego developers?"
> Not only could that discussion have been on dev@, it would have been
> better on dev@, because we *want* our branch policy discussions to be
> as transparent as anything else in this project.
>
> True, when we give new developers experimental branches, they might
> not know all our commit conventions. But we should view this as an
> opportunity! It's a chance to grow a new committer in a safe space,
> while getting some useful work done in Subversion. We'll just point
> them to http://subversion.tigris.org/hacking.html, and as we review
> the branch commits, we'll say when something not meet the guidelines.
> I don't really care if someone commits some junk the first few times,
> or messes up some log messages, or whatever. I don't even care if the
> majority of experimental branches end up going nowhere. Our revision
> history is not some pristine jewel needing protection.
>
> IMHO we should be *extremely* liberal in handing out commit access for
> experimental branches; I don't think we need private discussions about
> such commit access on s-f-c. Certainly, any discussions around this
> policy question should not themselves be private -- which is why I'm
> posting this mail to dev@, not s-f-c.
>
> The only sense in which an experimental branch is a resource drain is
> in its demands on our attention. Therefore, I think that any time a
> full committer offers someone an experimental branch, it is by
> definition appropriate and should be granted, because at least one
> committer has expressed a willingness to pay attention to that branch.
> This is specifically what I mean by a "liberal" policy.
>
> We're pretty good about making the project inviting for new
> developers, but we could be better, and this is one way to do so.
>
> Any objections to making such a policy official?
With all due respect to the time you've invested into this wonderful
explanation (and with apologies for the fact that I raised the question on
s-f-c despite my convictions that doing so was unnecessary), I think this
policy is already official. It just doesn't use the words "branch" anywhere.
This from hacking.html:
How partial commit access is granted
A full committer sponsors the partial committer. Usually this
means the full committer has applied several patches to the same area
from the proposed partial committer, and realizes things would be
easier if the person were just committing directly. Approval is not
required from the full committers; it is assumed that sponsors know
what they're doing and will watch the partial committer's first few
commits to make sure everything's going smoothly.
Does this differ significantly from what you've said?
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Nov 20 19:59:01 2007