[VOTE] merge lucene/solr development (take 3)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
126 messages Options
1 ... 4567
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] merge lucene/solr development (take 3)

Mark Miller-3
On 03/14/2010 12:12 PM, Otis Gospodnetic wrote:
> But I also recall people (Mark Miller maybe?) saying that the votes are not being counted and we are just looking to get an idea about the sentiment on this suggestion (paraphrasing him, sorry if I messed something up).
>
> Otis
>    

When I tallied up the in progress votes, I said it was not an official
tally because I didn't want to claim I could make that call. I was just
trying to show where people stood with the votes - kind of clearing that
out of the discussion. And to let people clarify if they didn't actually
mean to vote that way.

Technically, committer votes are not binding. That's why we had the
third vote - the PMC vote - really they are the only binding votes on
anything - though of course they should probably take the larger
community in mind when deciding how they will vote.

So the reason we had 3 votes, from what I saw:

The first vote was just to gauge the committers - technically, according
to Apache rules, committers can't actually confirm something like this
happening (though it does say some can have earned enough merritt to
have a binding vote - not sure who would decide that though). Apache
says that "those that do decide", but it also says that PMC members have
the only binding votes. Its an "interesting" intersection I'll admit.

The second vote was to change things so that Grant, Michael Busch, and
Andi were more comfortable with the proposal - they all liked the idea
of adding that Lucene could release without Solr. Mike McCandless
decided to change the proposal, and so we went with another vote.
Apparently we were all okay with that change.

The third vote was the PMC vote - that's really a vote that had to
happen, because they have the binding votes.

--
- Mark

http://www.lucidimagination.com



Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] merge lucene/solr development (take 3)

Otis Gospodnetic-2
In reply to this post by Michael Busch
Hi,

But remember the early days of this (or these) vote threads.  I recall some people saying things like "I won't vote -1 since I don't want to veto the proposal, so I'll vote +|-0".  I recall Doug being one of those people.  I don't think we heard back from Doug in subsequent vote threads.  I think there were a few others on the fence.

I don't think I even voted because things were not clear and there was too much discussion going on.  If I had to vote, I think I'd vote -1 mainly because I believe that what I think the proposal's goal is can be achieved with the current structure.  I mentioned this in some emails about a week ago, but nobody from +1 side reacted from what I recall.

I agree that in general in life it's impossible to get 100% of people to agree on something and sometimes that means that a "largish minority" will have to live with a change they disagree with, but here I feel that there are other ways of achieving the desired goal, so it's not clear to me while those less drastic ways are not tried first.  I'll send a separate email about those ways.

Otis



----- Original Message ----

> From: Michael McCandless <[hidden email]>
> To: [hidden email]
> Sent: Sun, March 14, 2010 6:28:57 AM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
> On Sun, Mar 14, 2010 at 12:26 AM, Michael Busch <
> ymailto="mailto:[hidden email]"
> href="mailto:[hidden email]">[hidden email]> wrote:
> This
> whole thing feels like it's been pushed through, and while I'm
> not
> against the updated proposal anymore (I voted +0), the bad
> feeling that
> consensus wasn't really reached remains.

But: this vote is not expected
> nor required to reach consensus.

We as a community are very used to only
> pursuing things when they
reach [near-]consensus, simply because nearly every
> biggish topic we
discuss must first reach consensus.  That's a very high
> bar and it
blocks many good changes (look at how many times we've
> broached
relaxing back compat policy...).

This change does not require
> consensus.  It requires only a majority
to pass, which it has
> achieved.  Yes, it's contentious, but a change
this big will always be
> contentious, and this is why Apache requires
only majority for it to
> pass.

Mike
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] merge lucene/solr development (take 3)

Otis Gospodnetic-2
In reply to this post by Grant Ingersoll-2
Hi,


----- Original Message ----
> From: Grant Ingersoll <[hidden email]>
> To: [hidden email]
> Sent: Tue, March 9, 2010 5:00:42 PM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
>
On Mar 9, 2010, at 12:38 PM, Otis Gospodnetic wrote:

>
>
>
> * I think Grant may be right.  We don't need this
> discussion.  Because the Solr/Lucene developer overlap is excellent, why
> not just start moving selected Solr code to new Lucene modules, just like Mike
> proposed we move Analysis from Lucene core to a new Lucene module?

Note,
> if you read what I said again you will realize I wasn't actually proposing
> this.  I was saying actually, that I think it would not be something that
> people really wanted, even though it is perfectly "legal", just like poaching is
> perfectly "legal", but isn't, in my mind a good solution.  Sigh.  The
> problem with email, I guess, especially on long threads.


My feeling was that majority of people said poaching (in a very positive sense) is the way OSS works.
Why can't we start with poaching/refactoring and then, in N months, evaluate both the outcome and the process and see if things can work that way in the future[*] or something more drastic should be done?

Additionally, if I understand things correctly, poaching is only needed when the code is not committed in the "right" project/location to begin with.

Otis
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] merge lucene/solr development (take 3)

Yonik Seeley
On Sun, Mar 14, 2010 at 2:36 PM, Otis Gospodnetic
<[hidden email]> wrote:
>  if I understand things correctly, poaching is only needed when the code is not committed in the
> "right" project/location to begin with.

That is the problem though - Solr should be allowed to keep whatever
code was written under it's control, w/o pressure to put it in Lucene
(and often out of reach).  And Lucene should be able to poach what it
wants from Solr.  But with the projects already half overlapping... it
was a recipe for conflict.

We've already had conflicts about this in the past.  The conflicts
were either going to get worse over time, esp with Solr not on
Lucene's trunk, or we were going to merge.  We've decided to tear down
the artificial wall and work together.

Some people suggest that this could have worked w/o merging.  I
disagreed, as I think the majority of those voting +1 disagreed.

Not sure who's following lucene-dev and solr-dev, but the committers
have already been merged. We're not standing still...

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] merge lucene/solr development (take 3)

Otis Gospodnetic-2
Hi,


----- Original Message ----
> From: Yonik Seeley <[hidden email]>
> To: [hidden email]
> Sent: Sun, March 14, 2010 3:48:10 PM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
>
> On Sun, Mar 14, 2010 at 2:36 PM, Otis Gospodnetic
<
> ymailto="mailto:[hidden email]"
> href="mailto:[hidden email]">[hidden email]>
> wrote:
>  if I understand things correctly, poaching is only needed
> when the code is not committed in the
> "right" project/location to begin
> with.

That is the problem though - Solr should be allowed to keep
> whatever
code was written under it's control, w/o pressure to put it in
> Lucene

But don't we want DRY?
And don't we want to take some of the goodness that evolved under Solr and modularize it, so that vanilla-Lucene users can benefit from individual pieces?

> (and often out of reach).

Does this remain true if we get Lucene trunk jar -> Solr trunk lib going on a regular (e.g. nightly) basis?

> And Lucene should be able to poach
> what it wants from Solr.  But with the projects already half
> overlapping... it was a recipe for conflict.


Poaching - right, it's just that if you build X in project A and then you want to move X to project B, it seems like more work needs to be done than if X was committed to B to begin with.

> We've already had
> conflicts about this in the past.  The conflicts were either going to
> get worse over time, esp with Solr not on Lucene's trunk, or we were going to
> merge.  We've decided to tear down the artificial wall and work
> together.

> Some people suggest that this could have worked w/o
> merging.  I disagreed, as I think the majority of those voting +1
> disagreed.

> Not sure who's following lucene-dev and solr-dev, but the
> committers have already been merged. We're not standing
> still...


Hm.
So there was talk of Lucene core and the new idea of Lucene modules, which are really just standalone libs/APIs/jars, right?
Would it make sense to think of Solr as one such Lucene module?
In other words, don't even bother with merging just the -dev lists, but really just merge everything.  In that case Solr's relationship with Lucene core becomes much like the relationship Lucene contribs have with Lucene core today in terms of compatibility, builds, and committers' responsibilities?

That kind of makes sense to me.  Of course, because of the sheer volume we may want to keep -user lists separate and possibly even create new ones for Lucene modules that attract enough interest on their own.

Otis

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] merge lucene/solr development (take 3)

Yonik Seeley
On Sun, Mar 14, 2010 at 2:58 PM, Otis Gospodnetic
<[hidden email]> wrote:
> Would it make sense to think of Solr as one such Lucene module?
> In other words, don't even bother with merging just the -dev lists, but really just merge everything.  In that case Solr's relationship with Lucene core becomes much like the relationship Lucene contribs have with Lucene core today in terms of compatibility, builds, and committers' responsibilities?
>
> That kind of makes sense to me.  Of course, because of the sheer volume we may want to keep -user lists separate and possibly even create new ones for Lucene modules that attract enough interest on their own.

Yes, the general gist of that all makes sense.  merge-everything is
more along the lines of the original discussion (we just needed to
enumerate some specific action items in the vote).  The things we
probably don't merge are just for user convenience.  Separate
downloads & websites & user lists.  Might have made sense to merge
JIRA, but there are just so many open issues... it prob wouldn't be
practical.

And yes, more user lists in the future could even make sense - say a
separate one for DIH.

-Yonik
1 ... 4567