Frankly it's not your vote that this project is trying to resolve, it's Ant's -1. The fundamental problem is that nobody seems to understand the basis for Ant's vote, Ant has been less than forthcoming about what it would take to change his mind, and the rest of the project is grasping at straws trying to figure out what to do.
That's not what mentoring at Apache is supposed to be about. My sole concern with this project is in how it arrives at its decisions, not in the outcomes. Healthy projects take advantage of their diversity by sampling opinions ahead of time and trying to form a consensus *before* putting things to a vote. Yes there is tension about the java code, but it's nothing that a dozen other Apache projects haven't dealt with in one way or another. Crafting bylaws has nothing to do with the problem, the project needs to construct productive working relationships between committers with different interests, while realizing that there should be agreement on what the common goals of the project are. ----- Original Message ---- > From: Upayavira <[email protected]> > To: [email protected] > Sent: Tue, December 14, 2010 9:53:55 AM > Subject: Re: [libcloud] Re: Removal of the Java bindings > > I have been thinking about this, and trying to address what my issue is. > Then I read the following on the wave-dev list: > > "It might be worth looking at what Lucene does vis-a-vis language ports: > It > looks like the ports (to Python, .NET, C, etc.) are separate projects, > but > the main lucene.apache.org page provides convenient links to each of > them. > <http://lucene.apache.org/> > > I don't see any reason something similar couldn't happen with Wave... > take > the C# Server that was being discussed, for example... it could enter > the > Incubator as a project in it's own right, with the two projects > providing > mutual links to each other, and with a "gentleman's agreement" between > the > developers to consult as necessary to deal with protocol compatibility, > etc. > > Just a thought..." > > I felt like this entirely captures what is going on with libcloud, and > if _this_ is the intention as to how libcloud operates, my issue in > regard to the Java impl goes away. > > The java impl can stay as it is, as a simple incomplete port in a > sandbox. If it reaches a sufficient level, it can become a 'clone > subproject', or, be extracted out into its own project, whether under > incubation or as a TLP depending on community maturity. > > The remaining issue expressed by Ant was regarding over-reliance on one > person, Paul. > > I have mulled further on this, and have also come to the conclusion > that, for me, this is a non-issue. > > I have viewed Paul as a driving force in the project. However, take him > away, and we still have active participation from others (maybe not > 'lead' but participation, and ASF projects do not require a leader to > succeed). > > Also, reviewing some simple metrics show that he is not over-dominant: > <50% of commits[1] and a small proportion of Jira issues[2]. > > Therefore, were this vote presented to the incubator PMC, I would now > vote +1. > > Upayavira > > > [1] http://www.ohloh.net/p/libcloud/contributors > [2] >https://issues.apache.org/jira/secure/ConfigureReport.jspa?versionId=-1&issueStatus=all&selectedProjectId=12311030&reportKey=com.sourcelabs.jira.plugin.report.contributions%3Acontributionreport&Next=Next >t >
