lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "patrick o'leary" <>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Sun, 14 Mar 2010 03:36:22 GMT
I do appreciate you reaching out to me, but I think this needs to be an open

Folks, have used the terms *bullied*, *rail-road*, and *pushed* to describe
this vote, folks that aren't even me.

I look at development that's occurring in solr and I am concerned, I don't
feel that it's serving the community.

I've seen comments on threads of (paraphrasing) person X,Y,Z voted and are
committers  and they are the guys who do the work, so that's all that
Well no, the community contributes code, ideas / concepts, but
the committers seem to sit on these ideas, unless it meets a feature they
want. I can bring several examples to display this, and not just localsolr.

If you want a concrete example take Field Collapsing

That's been around 3 years now, has 61 votes and 72 watchers, yet it's been
sat on... the community has delivered, but committers have refused to heed
It's it complete?
I feel it's more complete that all the function query work that was
committed to Solr trunk for spatial solr...
It's clearly shown there's two sets of rules for this, as a committer you
can do as you please, as a community member you've got to hope that there is
a committer who needs what you've done or asked for, and agrees with the way
you've implemented it..

That's where I feel there is a lack of diversity in concepts, direction and
design within solr.

And as such I would hate to see the same thing happen to lucene.

Granted we all work for a living, we can't always work on projects or ideas
others bring to the table. I write code maybe once a month these days, and
often can't keep up with the requests that come into the open source stuff I
support. But I've always allowed others to contribute and extend, if it
compiles, works, and doesn't mess things up, I always feel that if it's
important enough, then iteration will make it better if it needs to be
better. And I've been lucky that several folks on the locallucene world have
rolled up their selves and helped out.

I respect, and appreciate folks for taking any hemorrhage of concepts and
making them better, and that's how see open source working.

Apache provides hosting, and legal protection for people who develop
community driven projects, but not projects that are restricted to the ideas
of those that have commit karma.

As for this vote, I will allow our proximity to St. Patricks day to tone
down my description of it, by describing it as shenanigans !

Patrick O'Leary

On Sat, Mar 13, 2010 at 6:23 AM, Yonik Seeley <> wrote:

> Hi Patrick,
> I understand some of your concerns with the vote - it certainly wasn't
> perfect, and (I believe) could never be unanimous.  But it's done, and
> the merge is already moving forward, so I'd like to put that behind
> us.
> I did want to take some time to address any concerns you had about the
> actual dev merge though (impacts on Lucene and Solr).  There will be
> some negative impacts to Solr and some negative impacts to Lucene, but
> overall it seems like the good will outweigh the bad.
> On Mon, Mar 8, 2010 at 10:16 PM, patrick o'leary <> wrote:
> > Hmm, Right now I consider Solr too far from lucene to see a merge
> succeed,
> > if you asked me 2 years ago I would have said merge merge merge.
> If you mean just getting back onto Lucene's trunk, this shouldn't be
> too big of a job.  And it certainly won't have any impact on Lucene
> before we do.
> > I also think Solr hasn't worked out a good roadmap or schedule for
> releases,
> > which I'm sure will impact the lucene world.
> I've never really seen much in the way of roadmaps from Lucene either.
>  And since Solr became open source, Lucene as only had one more major
> release (not counting 3.0 which just removed deprecations).  The
> bugfix releases are easy in comparison - I don't see problems with
> those.
> Now, it's certainly possible that Lucene could impact Solr's schedule,
> and vice-versa... little slips will happen on both sides.  If
> extenuating circumstance arises where Solr is clearly not close, but
> lucene is, then we can always opt to not release the Solr artifacts
> (that's the clause that Mike spelled out in VOTE #2 to ease fears
> about that).
> Again, there can be any number of little potential disadvantages to
> the merge... but there are also a ton of positives, and  the main
> point is that we'll be working hard to make sure the good outweighs
> the bad.
> -Yonik

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message