Fair questions, Troy, let me see if I can provide some info, as well as some other thoughts.
On Dec 30, 2010, at 1:30 PM, Troy Howard wrote: > Grant, > > I think the problem at this point is that the community at large does > not understand why a change of status is necessary to continue the > project. > OK, so here's the ASF in a nutshell. The ASF's mission is to produce open source software under the Apache license. This is essentially it's charter as a 503(b) (?) non-profit organization. From the top down, the ASF has a Board of Directors who then delegate the responsibilities of project management to a Project Management Committee (PMC) that consists of a PMC Chair (me) and zero or more other members. The PMC is responsible for the oversight of the projects as well as the election of committers to the project. Oversight primarily comes down to telling the Board whether things are going well or not as well as checking out and voting on releases. Occasionally, we have to deal with trolls and other bad apples. We also do some infrastructure work such as managing our areas of SVN and JIRA, Wikis, etc. We are all volunteers as far as the ASF is concerned. To that end, committers have the right, earned by demonstrating merit through interacting with the community and contributing patches, etc., to change the code. Any given project should be able to sustain the loss of one or more committers because there are others willing to do the work. It is often the case, but not always, that PMC members and committers are the same people over a period of time. In other words, if you stick around as a committer long enough, you should be a PMC Member at some point. Committers, and thus all PMC members have signed Individual Contributor License Agreements with the ASF stating that we have the right to donate the code that we do. As committers, part of our job in reviewing patches is to make sure it is proper to commit that code to Lucene. At the end of the day, it really is all about the community of users and developers that surround a particular piece of code and not the name on the project. If you look at the Lucene PMC, it is made almost entirely of Lucene/Solr committers plus George from .NET and Andi from PyLucene. To some extent, the Board does not recognize sub project organization in the sense that the PMC is ultimately held responsible. Sub-projects were done by this PMC along time ago as a matter of convenience. I believe I am not alone in stating that the convenience of sub-projects from a PMC standpoint has been outlived for many of the Lucene sub-projects, as was thoroughly discussed during the spin-out of Mahout, Nutch, Tika and Lucy. So, to your questions. > Does Lucene.Net have to back to the Incubator and become a TLP? I suppose you could petition the Board to go directly to TLP status, but I highly doubt, given the track record of the project that they would approve it. If they asked me my opinion, I would advise against it given what I see as the state of the community. If you would like, I am willing to ask the Board what they think should happen to a sub-project that has active users, but no active contributors and a PMC that is no longer interested in maintaining the project. > Why is > this beneficial to either Lucene.Net or the existing Lucene TLP? It is of no benefit to the Lucene TLP. Frankly, this is a hassle to me, albeit a necessary one. If the .NET contributors/committers were active and made reports on time (once a quarter, it's not like it is onerous), we likely wouldn't be having this discussion. I know why some committers have not been active and I don't blame them. Life happens, but the unfortunate side effect is that the project has stagnated and this PMC as it is constituted is not interested in maintaining it. As for the benefit to .NET, I think it is a huge one, assuming that people step up. There will be new committers. You'll get to keep the name. You'll be, within the confines of Board direction, self-ruled, meaning you choose when to do releases, who to elect as committers, etc. This is a very good thing for .NET, assuming it can sustain itself. > > Why was Lucene.Net moved to Lucene sub-project status in the first > place? Why is that no longer a reasonable place for the project to > exist? I've explained this at least 5 times in previous emails. The interests of this community are not aligned with the interests of those who make up the PMC. We on the PMC have no way of judging whether someone has earned the right to commit or not, nor do we have the capacity to vote on releasing .NET artifacts because none of us use .NET. > > To me, a port of Lucene belongs as a sub-project of Lucene. > I used to think that way, but no longer do mostly because of the PMC organizational issues. If you looked at mailing list subscribers, I would wager to bet that I am one of the few Java users who actually subscribes to this mailing list and is even aware of what goes on here. So, while the name is the same and you are porting the Java code to .NET, there is almost no interaction between the communities as they are quite distinct. I suspect many .NET users go to the Java community to get answers, but I doubt any Java users would look to the .NET community for answers. I think you will find that as a TLP you actually have a higher profile. > That said, I've noticed that Lucy has recently moved in the same > direction for the same end goal of becoming a TLP, however PyLucene > has not. The inconsistency is confusing. In the long term, PyLucene may standalone. There is, however a big difference in the two communities. Namely, the one committer who is mainly active on PyLucene is active and consistently tracks the Java version. New releases of PyLucene are almost simultaneous to the releases of the Java version. Moreover, the committer responds to patches quickly and also is responsive to PMC status requests almost immediately. Also, note, PyLucene is really just a wrapper around the Java version, as opposed to a port of the Java version. AIUI, it still runs in the JVM and really is just Python bindings around Lucene. Finally, there are others on the PMC besides the primary committer who take an interest in PyLucene (myself from time to time and Mike McCandless and sometimes Robert Muir) > > Regarding putting together a proposal to the Incubator, I will gladly > do that work, as well as assembling a group of committers. However, I > don't feel like I yet understand why the project needs to do that. > > It seems to me that simply bringing in new committers without changing > the project status is the best course of action. It's also the least > amount of work in terms of infrastructural changes, etc. Beyond that, > the project *just* graduated out of the Incubator... I don't think it is proper for this PMC to vote in committers who we have no idea whether they are up for it or not. The Incubator is specifically designed to flesh out those kinds of questions by bringing in untested committers into the ASF. > How often does a > ASF project need to go through this process of status change? Did it > not already prove itself and end up at the most reasonable > destination? Back then, yes, it probably did. And then life happened and things changed. Back when it joined Lucene, all the committers were active and many of us felt an Umbrella PMC was beneficial. Since then, the Board has asked us to review our Umbrella status for a number of reasons, the biggest of which, in my mind, is the fact that disparate communities under a single PMC often end up at odds over direction and are subsequently stalemated. > > Thanks, > Troy > > > > > On Thu, Dec 30, 2010 at 9:32 AM, Grant Ingersoll <[email protected]> wrote: >> >> On Dec 30, 2010, at 9:51 AM, Heath Aldrich wrote: >> >>> Hi Grant, >>> >>> Thanks for taking the time to respond. >>> >>> While I have developed extensively against Lucene.net, I do not possess the >>> java skills needed to do a port of the code... So, while I wouldn't mind >>> being a committer, I do not think I am qualified. (I guess if I was, I >>> could just use Lucene proper and that would be that) >>> >>> As to other duties of a committer, I think the ASF is perceived as a black >>> box of questions for most of us. >>> >>> For one, I don't think anyone outside the 4 committers even understand >>> *why* it is a good thing to be on the ASF vs. CodePlex, Sourceforge, etc. >>> Maybe if there was an understanding of the why, the requirements of the ASF >>> would make more sense. I think a lot of us right now just perceive the ASF >>> as the group that is wanting to kill Lucene.net. >> >> I don't think we have a desire to kill it, I just think we are faced with >> the unfortunate reality that the project is already dead and now us on the >> PMC have the unfortunate job of cleaning up the mess as best we can. Again, >> it is not even that we want to see it go away, we on the PMC just don't want >> to be responsible for it's upkeep. You give me the names of 4 people who >> are willing to be committers (i.e. people willing to volunteer their time) >> and I will do my best to get the project into the Incubator. However, I >> have to tell you, my willingness to help is diminishing with every trip we >> take around this same circle of discussion. >> >> Simply put, given the way the vote has gone so far, the Lucene PMC is no >> longer interested in sustaining this project. If the community wishes to >> see it live at the ASF then one of you had better step up and spend 20-30 >> minutes of your time writing up the draft proposal (most of it can be copied >> and pasted) and circulating it. In fact, given the amount of time some of >> you have no doubt spent writing on this and other related threads you could >> have put together the large majority of the proposal, circulated the draft >> and got other volunteers to help and already be moving forward in a positive >> direction. Truth be told, I would do it, but I am explicitly not going to >> because I think that if the community can't take that one step to move >> forward, then it truly doesn't deserve to. >> >>> >>> I get your comments about the slower than slow development, but that is >>> also somewhat of a sign that it works. While 2.9.2 may be behind, it seems >>> very stable with very few issues. If we send the project to the attic, how >>> will anyone be able to submit bugfixes ever? Frankly, I use 2.9.2 every >>> day and have not found bugs in the areas that I use... but I'm sure they >>> are in there somewhere. >>> >>> As for the name, I thought Lucene.net was the name of the project back in >>> the SourceForge days... >>> So my question is based on the premise that "if the lucene.net name was >>> brought *to* ASF, why can the community not leave with it?" >> >> Again, IANAL, but just b/c it was improperly used beforehand does not mean >> it is legally owned by some other entity. The Lucene name has been at the >> ASF since 2001 and Lucene.NET is also now a part of the ASF. (If your >> interested, go look at the discussions around iBatis and the movement of >> that community to MyBatis) >> >> -Grant -------------------------- Grant Ingersoll http://www.lucidimagination.com
