forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject committer vs write access
Date Thu, 08 Sep 2005 19:09:27 GMT
At risk of keeping this going, I'll give my own thoughts on what
you've said.  I've moved this out of the vote thread too.

> ****************************************************************
> As well I want to take the opportunity for to make a statement.
> I did a senseless comment on the beginning of this vote that did not
> reflect the situation that we now have. I was talking about simple
> committership when calling the vote. That was not correct as *I* really
> see it.
> Yes defines the
> role committer as follow:
> "committer is a developer that was given write access to the code
> repository and has a signed Contributor License Agreement (CLA) on file.
> They have an mail address. Not needing to depend on other
> people for the patches, they are actually making short-term decisions
> for the project. The PMC can (even tacitly) agree and approve it into
> permanency, or they can reject it. Remember that the PMC makes the
> decisions, not the individual people."
> The thing that I do not like on this description is that is missing one
> important (and IMO the most important) point expressed by David in
> another thread:
> On Sat, 2005-09-03 at 10:18 +1000, David Crossley wrote:
> > We would not become "committers" at Lenya or Cocoon,
> > just get "svn access". To become committers proper
> > we would go there, participate on their mailing lists,
> > help users, be committed to the project, etc.

It is *not* missing that important point.  In the definition, it says
commiter += developer -- meaning to get the full definition, one needs
to read them together.  This is particularly important here because
developer is where the definition expects those community aspects to
happen.  The definitions are rightfully based on meritorious
progression in the "roles".  We're having this problem reconciling
non-developers, non-contributers having write access to the code
repository only because we're giving them write access without having
earned it the way others do by progressing from user->dev->committer.

I think the situation David is describing here lessen's significance
of ASF Committership.  I mean shucks, if I've got svn write access
anyway, committer is just a title, not a role.  They both can checkin
code but neither has a binding vote.  I've asked twice now what the
*pragmatic* difference is between committer and "one who has svn

> I miss in above official description the point to *be* committed and
> what this actually mean. David pinpointed this very nice. To *be*
> committer in a project means that you "participate on their mailing
> lists, help users, be committed to the project, etc."

see above

> I repeated our discussion about simple committership vs PMC on the lenya
> dev list. Michis answer seems very interesting in the light of the above
> said.

I read this as "why buy the cow, when you can get the milk for free". 
If we trust them with write access to the code repo, then we should
trust their binding vote.  Anything else is "club-ish" and subject I
> He actually is using the official definition of the ASF to fuel his
> argumentation. That has the certain background that Michi has a company
> where they use lenya for customer projects. Now his employees are
> sending tons of patches everyday and we do not have the time/resources
> to cope with all of them. The solution of simple committership seems
> logical.
> Now let us recall what David said, to *be* committer in a project means
> that you "participate on their mailing lists, help users, be committed
> to the project, etc." The important point that I see in this is that
> David points out that the community building makes you a committer not
> so much the code contributions. This is as well my opinion. IMO we find
> a definition ASF wide to redefine the committer role.
> Clearly forrest committer are not automatically lenya committer and vice
> versa even if they meet the official ASF definition for this role. The
> situation we have now I see only as leveraging projects that have the
> same roots and were we can use synergy effects. Like stated by Ross it
> helps to just go ahead to apply your own patches on a "foreign" project
> where you have write access.

Is there anyone that would really apply patches to a "foreign" project
without being a "developer" in the true ASF sense of the word?  I
doubt it.  Our situation is a little different and more akin to GSoC
and could probably have been favorably solved in the same way Cocoon
did their GSoC folks.
> I actually using this right @cocoon to fix typos and small things in
> their code base. The argument that I could create a patch and attach it
> to the issue tracker is not logically for me, because even if it takes
> me "only" 3 minutes, it will at least take another 3 Minutes for the
> cocoon committer that is applying my patch. Now simple math tells us
> that with 10 patches we spend 60 min on something that would normally
> take less then 10 min if I am doing directly.
> As soon as I have bigger changes I will create a diff and ask on the dev
> list to discuss this patch before applying it. I even do it sometimes on
> lenya and if I would change the forrest core I will do it here.
> I hope that I clarified my sloppy comment.
> salu2
> --
> thorsten
> "Together we stand, divided we fall!"
> Hey you (Pink Floyd)

Anyway, I know that this sort of banter is being frowned upon of late,
but it's very interesting to me.

View raw message