lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Fri, 12 Mar 2010 14:24:31 GMT
You have come a long way from "If that means I get overruled, so be it." 

Its a PMC vote where majority rules. As Bernd noted, vetoes are for 
specific svn
commits with valid technical reasons. If you guys want to try and drag 
it out forever,
I don't see much to stop you from trying, but the whole situation is 
pretty clear.

I, for one, am looking forward to what this merge will bring to Lucene 
and Solr.

On 03/12/2010 09:15 AM, Dennis Kubes wrote:
>  Yes railroading.
>  Many people don't want this to occur.  More than just minus 2.
>  Underlying concerns are not being addressed.  Vetos count.  Ignoring
>  that is ignoring how Apache operates.  Merging projects is definitely
>  a code change.  Getting around it by saying this is a goal is
>  fundamentally wrong.
>  1) What prevents functionality be moved over into Lucene within the
>  current project structure?  Nothing, so why are we even discussing
>  this.
>  2) Why is Solr getting special treatment?  Because there is a lot of
>  committer overlap?  Should I propose to merge Nutch in too, lets just
>  have one big project, no distinctions.
>  3) Why the big push here to blur project responsibilities? Idk, I
>  keep wondering that myself.
>  Dennis
>  Grant Ingersoll wrote:
> > On Mar 12, 2010, at 7:54 AM, Dennis Kubes wrote:
> >
> >> This has definitely NOT passed.  With as much contention,
> >> discussion, and debate as there has been on this, saying that it
> >> has passed is akin to saying "we are just going to do it
> >> anyways".  This is being railroaded IMO and needs to be taken to
> >> a higher level within the Apache organization.
> >
> > How is two weeks of discussion and all the committers on the
> > projects minus 2 being for it and three different votes on it (all
> > with the same outcome), "railroading"? -Grant

- Mark

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