--- Greg Stein <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 23, 2002 at 06:20:05PM -0700, Morgan
> Delagrange wrote:
[snip]
> > 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?
Sorry, I think the lack of clarity here gave my email
the wrong connotation. Let's rephrase it as "I
supported allowing any j-c committer to vote on any
component, because it simplified (removed, actually)
the barriers between components". All my subsequent
statements were with regard to committers (people who
had already obtained commit access via substantial
code contributions).
> > 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.
My fault for not being clear. I'm referring to people
who are _already_ committers, but are making
contributions to a new component. It's more difficult
to track their contributions because they're already
"in", and in any event it becomes awkward to say with
every vote, "ok, who's _really_ helped out, and who
just sort of helped out."
> 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.
Yup I don't dispute that we should have high standards
for commit access. However once they've become a
committer, I think they should work on any components
they choose which (I think) you support too.
> > 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.
I agree. Sometimes I wish there was a little more
busting going on.
> 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.
Just to be clear, is there one bar for commit access
to all components, or a bar for each component? If
it's the former, then I agree. I also _may_ agree in
slightly finer gradations, like one bar per language.
But having to gain commit access to each Apache
Commons component despite having commit access to
other components is too restrictive.
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
