lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: [VOTE] Merge the development of Solr/Lucene (take 2)
Date Tue, 09 Mar 2010 22:38:38 GMT

: > I still don't like that we're voting on a "Goal"
: 
: I don't quite understand what you mean here.  As I read it, the proposal 
: from Michael is pretty specific on details.

We are not voting on commiting a specific patch, or releasing a particular 
bundle of source code, or on select a logo from a finite set of entries, 
or on giving a person commit karma -- we are voting largely on the 'idea' 
that development should be merged.

Only two aspects of "the proposal" are concrete and actionable: merging 
the dev lists, and merging the commiter lists -- those are the only two 
bullet points that can be voted on and pass with a clear and obvious 
immediate ction an effect.  To anyone with knowledge of knowledge of the 
ASF, those bullet points are almost completley unambiguoius.

The rest of the proposal is vague and subject to interpretation -- at best 
it articulates "things that we would like to see happen" without any 
indication of how these things should/will happen.

Casting a vote in favor of "When any change is committed (to a module that 
"belongs to" Solr or to Lucene), all tests must pass." is meaningless.  
If Solr didn't exist, We could just as easily vote that "All 
Lucene-Java tests should pass whenever a commit is made to Lucene-Java." 
-- so fucking what? ... It sure seems like a good idea, but what does it 
mean to vote on it?  Doees it mean that you lose your commit privliges if you 
commit code that causes a test to fail?

Even if we all agree 100% with the "goal" that nothing should be committed 
to either Lucene-Java or Solr that would break a test in either code base, 
so what? ... how to we enforce that?  What types of (concrete and 
actionable) approaches do people suggest to making sure that changes in 
one code base don't break tests in another code base?

Let's hear proposals for how to *implement* that goal, and then lets vote 
one those.

Likewise for "Modulariize the sources ...."  Modularization is a hot 
buzzword, so i'm all in favor of this idea, i'll totally vote for that.  

Now what?

The next step is probably to have a discussions about what exactly we want 
to modularize out first, and how we want to do it, and where it shoudl 
live in svn, and how it should fit into the build system, and which way 
the dependencies should go, and what API changes might be needed to make 
this work in a generic way, and why the fuck can't we just have this 
conversation independent of a big as "let's vote on something" thread?

The shear number of "wait, i thought this part of the proposal ment 
that ..." comments in the "take3" 
thread should be evidence enough of my point about ths VOTE being 
too "goal" orriented when we should be talking about what identifiable, 
incremental steps we can take towards solving the problems we see.

: > incrementally -- preferably starting with some basic refactoring/merging 
: > of specific components/modules (akin to McCandless'ss original suggestion) 
: > and adjusting committers/mailinglists/build-processes however it makes 
: > sense as we go along.
: 
: I just don't see how specific components will work.  Say we spin out 
: analyzers but Solr doesn't move up to 3.0.x immediately.  What incentive 
: is there for a Solr committer to work on a new Analyzer in the Analyzers 
: project as opposed to Solr?

I have no idea ... what incentive does a Solr commiter have to work on 
anything in the Lucene-jaava code base once this VOTE passes?  What 
incentive does any committer have to do anything?

We seem to have me confused with someone who has said "I percieve a 
problem, here is a goal i think we should set out for it, let's vote on 
that" w/o hasing out the steps i think we need to reach that goal.

I'm not suggesting a goal, I'm not even suggesting any particular actions.  
I'm suggesting that if there are people who percieve problem (and there 
seem to be plenty of these folks) then we should discuss what those 
problems are (seem to have a good start on this part) and then discuss 
actionable, *technical* solutions to those problems (ie: if 
duplication/divergent code is a problem, then let's talk about what 
specific refactoring/modularization can help) and then let's try one or 
more of those specific actions and see if it improves the situation and 
iterate from there.

-Hoss


Mime
View raw message