On Wed, Oct 23, 2002 at 06:20:05PM -0700, Morgan Delagrange wrote:
>...
> > The 'intent' (IMHO, of course) of the j-c commit
> > model, was that everyone had avail access to all
> > code, but you had to add yourself as a member of the
> > project before you committed to it. This was
> > ultimately end run where people would just add
> > themselves and then veto,
Yup, I can see that, and your comment that it actually occurred causes me
worry. The merit-based approach that I described is designed specifically to
inhibit such behaviors.
[ well, "designed" is a bit strong... you could say it evolved and is part
of the basis for that nebulous term "Apache Way" -- you only get to vote
if you're an active participant ]
> > but I think the general
> > idea of gaining access to a project is a good idea.
It does tend to work well :-)
> > The most useful thing here is that since j-c has so
> > many smaller projects (in terms of code size), that
> > anyone willing to review and commit a patch is a
> > good thing. If you don't know much about the
> > component, you don't commit the patch, but if you
> > have a good idea about, but just not the bandwidth
> > to completly participate, commit the patch. Some
> > may disagree with this, but I am a firm beleiver, as
> > the codebase size approaches zero.
Yes, this can be handy for small codebases. I might respond that the correct
answer is to aggregate those codebases. You end up turning 10 small bits,
each with one committer, into a larger group where patch review and
application can be shared by 10 people.
Let's look at your comment in a bit more detail:
* "anyone willing to review and commit a patch is a good thing"
The more, the merrier, yes. And anybody *can* review a patch. You don't
have to be a committer to do that. In fact, doing this is a step towards
earning your commit rights. It can show how you work with others, that you
have interest in the codebase, that you be constructive, and that you're
willing to spend the time.
The part about committing is trickier, though. "anyone" can create real
problems, as I've explained elsewhere. A drive-by committer might not
understand enough to be responsible for the commit. Worse, they might not
realize that, think they know what is up, and commit away...
* "if you don't know much about the component, ..."
This rule is easily handled by the merit-to-commit rule. Your demonstrated
knowledge of the component gets your commit privs. If you don't know
anything about the component, then you're already denied the ability to
commit patches.
* "if you have a good idea about, but just not the bandwidth to participate,
commit the patch"
This one is a bit tougher. If you've earned the commit privs in the past,
but aren't participating much any more, then this can be a good thing.
You have one more person who can help the project. Of course, lack of
active participation might also mean you suffer bit rot, and fall into
the "not knowing" category, but it is best to assume that any previous
committer is still competent. (i.e. once you're in, then you're in for
life :-)
The harder problem is the relatively inactive person who probably knows
their stuff, but hasn't demonstrated particular interest/merit for the
given component. How do you take advantage of their time and inclination
to apply patches?
a) too bad, the patch just sits idle
b) lower your bar for officially granting commit privs (the PHP people do
this to great effect)
c) depending upon the karma setup (CVSROOT/avail), the person might have
the technical ability (but not the Right) to do the patch; but a real
committer might say, "looks good. can you handle applying it?"
The Subversion team does this well; we have a lot of committers that
are "scoped" to only work in particular areas, but they can
technically commit anywhere; if they come up with a patch "out of
their area", then they sent the patch to the list and get a +1 on
applying it. This allows the main devs to apply some control and
though to what goes in, yet distributes the load of patch application.
> I'm also not necessarily attached to the free voting
> part of j-c except insofar as it doesn't restrict
> people from contrtibuting to all components without
> calling some sort of karma vote.
Hmm... I'm not sure how to parse that sentence. Could you rephrase?
> The problem is where to draw the line.
>
> Someone who edits a single javadoc shouldn't vote, but
> someone who cleans up all the documentation should.
> Someone who fixes a typo in an excecption shouldn't,
> someone who fixes exception handling should. Someone
> who fixes a single significant bug should, shouldn't,
> who knows?
Merit answers all of these. If somebody supplies you with single-line
patches for a long and consistent period, then give them commit access.
Presumably, they'll continue applying the same kinds of changes. If they
just send a single patch, then they wouldn't get the commit privs, so you've
already answered your question on where the line is.
If somebody is sending in big patches that really hit everything or show a
critical understanding of the code, then give them commit access so they can
directly apply their energy.
> It's a difficult issue on which we punted
> at j-c, erring on the side of inclusion. If you want
> to take it on, then find that magic formula to figure
> out when a contributor "counts". I'm not saying it
> can't be done, but make sure you make an informed
> choice. And be aware that someone who is truly petty
> will find a way to subvert any rule you formulate.
> That's why we chose to just trust people's judgement.
If somebody subverts the rules, then you bust them. Pretty darned simple.
The "magic formula" is have the committers on a component determine when a
prospect appears to "get it" and is given commit privs. Human judgement is
involved in that decision, and gives you a way to decied when a contributor
really "counts".
Of course, there is the possibility that an existing set of committers won't
give a consistent contributor their own commit privs. That can be a problem
and would be something for the PMC to deal with ("this person appears to be
a solid contributor. why don't they have commit access?")
If you want to err on the side of inclusion, then set the bar low for commit
access. But that gate should be there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
