Hello devs, I counted Positiv: 4 binding votes (+1) and 1 non-binding (+0) Negativ: 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 http://apache.org/foundation/how-it-works.html#roles 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 apache.org 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 said. http://marc.theaimsgroup.com/?l=lenya-dev&m=112539704200829&w=2 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. 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)
