-0.02 as I'm no committer (but I was considering to involve myself more..) I'm very concerned about this point: "Release both at once"
All other ideas sound reasonable, but this one is dangerous: why enforce upon yourself such a binding limitation? There might be plenty of good reasons to release a new version of Lucene while Solr is not ready yet, and still other products might begin working with a new Lucene version or integrate some urgent fix. I love Solr, but there's more out there: Alfresco, JIRA, liferay, hibernate search, elastic search, mahout, CQ5, confluence, Hippo, and many more ... that means plenty of communities which might want to contribute to Lucene but don't have a priority to dive into Solr. It's possible you'll have to release one of the two without any change, just to release the other for some urgent fix: this will have people waste time upgrading for nothing, or read an empty changelog and wonder about the madness in the world. Not to mention your own effort as time for releasing ? It's all fine for me, I just suggest to not make this a binding rule as it will likely hurt yourself. regards, Sanne 2010/3/4 Grant Ingersoll <[email protected]>: > > > On Mar 4, 2010, at 11:09 AM, Mattmann, Chris A (388J) wrote: > >> >> +1 again and this is also one of my main objections to the proposal as it >> stands. Let the community decide who the committers are, and let each >> community decide what version of software it depends on. I'm not convinced >> that they are the same communities for that matter, and statements made >> earlier about Solr being the biggest user of Lucene(-java) may be true from >> a Lucene ecosystem perspective, but I disagree it's true (or even provable >> for that matter) from an external perspective given Lucene(-java)'s >> widespread use predating Solr as an Apache project, and Lucene's infection >> into other communities (e.g., PHP with Zend, etc.) > > So, when those projects donate themselves to Apache, we can manage them, > until then what we are proposing would have absolutely no effect on them. > They'll still get their Lucene JARs just like they always do. I don't hear > anyone proposing to gut those projects. The fact is, Solr is managed by the > Lucene PMC and it is our responsibility to make sure we produce good software > under the ASF model. That doesn't mean we have to merge, but, there are a > good chunk of committers and others who feel some improvement on the current > situation is necessary. Moreover, many people want what is in Solr, but > don't ever work to keep it whole. From a PMC perspective, that's not fair to > Solr even if it benefits Lucene and is perfectly "legal" and vice versa, so > as a PMC member I don't like that situation. Furthermore, as a committer on > both projects, I don't like the duplication of effort and I don't like having > to choose between the two when I know that my changes would benefit both > communities but am forced to do so solely on the arbitrary fact that way back > in 2006 when CNET donated Solr they said "Let's make this a subproject" > instead of saying "Let's make this a contrib/feature of Lucene". I often > choose Solr these days solely b/c it means I can get access to it sooner from > an end use perspective and nothing else. > > The fact is, the PMC is who releases software, not individual committers or > even individual subprojects. The fact that their is a Solr and a Lucene is > almost an arbitrary distinction, at least in the early days. Nowadays, it's > obviously grown, but it still is the PMC that releases both. > > -Grant
