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