forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject [Summary][Vote] giving svn access to lenya commiters
Date Thu, 08 Sep 2005 18:25:47 GMT
Hello devs,

I counted 
4 binding votes (+1) and 1 non-binding (+0)
2 negative none veto votes (-0) which have been binding votes.

That means we officially allow lenya committer to have write access to
our code base. They are *not* voted in as committer.

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.

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."

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

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

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. 

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.


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message