: Or, two committerships, two projects. So, if the existing committer structure : were acceptable, then Solr would be split to a separate TLP. That is the more : common direction, for things to be split into separate TLPs as they grow. : Merging is an unusual experiment.
In trying to look at the situation impartially, i think what really makes the Lucene-Java/Solr situation unique (in at least as much as i understand how other TLPs have formed in the past) is that while the user communities of the two "products" have diverged (or any many ways, never really been aligned) the developer communities and feature sets have in many ways converged over time. Lucene beget Hadoop because the Hadoop users/developers diverged from the Lucene users/developers and the Hadoop features diverged from the Lucene (ie: Nutch) features and use cases. As i understand it, something similar happened with HTTPD/APR: APR's developer community (and certainly it's user communities) started having less and less overlap with people who were focused on building a webserver. In our case, more and more Lucene-Java developers started wanting to work on the guts of Solr, and more and more developers as a whole wanted to see better melding/refactoring of functionality across Solr/Lucene-Java -- In terms of "getting things done" creating a new TLP wouldn't have really helped that situation, it would have just simplified the politics. Regardless of how ugly it was the watch the sausage getting made (and regardless of my personal frustration with the voting insanity) i think that in the short term, and medium term, the decisison to "tear down the walls" dividing the two developer communities will certainly help improve both products and eliminate duplication of efforst ... even if in the long term it is ultimately decided that it Solr should be it's own TLP. -Hoss
