lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanne Grinovero <sanne.grinov...@gmail.com>
Subject Re: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 19:57:03 GMT
-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 <gsingers@apache.org>:
>
>
> 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

Mime
View raw message