lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 19:34:44 GMT
Hi Grant,

>> +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.

Actually it will have a profound affect on them, as it'll define when, how,
where and why they get those JARs as that is dictated by those that release
and prepare them, the entity on the table that is being proposed to be

> 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.

So why does that require "merging" the projects in the way proposed? I'm
sorry I still don't buy into that? Why do we need to merge the committers of
both projects into 1? So Solr committers can touch Lucene code, and update
it? If that's the case, then propose the set of Solr committers that should
be Lucene committers and call a vote on that. Or, vice versa. That way you
can gauge feedback from the community on whether or not those being voted on
have made enough contribution to be approved in. That's the Apache way, as I
understand it. 

> 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.

This is why I was suggesting that perhaps a new TLP might make sense then
for Solr, or potentially even Lucene. Why not start there instead of this
approach being proposed? If the Lucene(-java) committers and Solr committers
want a shared project between them, based off of 2 existing ASF projects, in
essence to merge the code base and ensure that both are aligned and not
duplicated, propose that and let's vote on that. That's not what I'm hearing

> 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.

Understood, I hear ya.


Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message