On Apr 26, 2011, at 7:43 PM, Michael Busch wrote: > I totally agree with Robert and Simon that it is currently very frustrating > that moving code to Lucene is being veto'ed on.
What has been vetoed on? The response veto today? That hardly counts right? Just part of today's BS fun. If you guys are letting yonik stop you before you even begin - I suppose with a glance - than really, thats your issue IMO. Consider this: if you did the work necessary to make join a module and polished it all off and submitted it to Lucene - you think yonik standing alone would block that? I find this a very weak argument. Perceived road blocks are certainly no roadblock. Revert wars are a road block. Making challenges or pointing things out are not road blocks and should not be frowned upon. The good stuff makes it past that IMO. You could make the same argument against all us comitters - we are all road blocks, because we all question patches from new contributors (and old). I had to adjust my highlighter patch for a fricken year before it was committed. Did I claim road block? No - I worked on the damn highlighter until it went in. This leads us back to more rehashing though...not the elusive solution... > It doesn't necessarily even have to take longer to develop a new feature as a > shared module vs. one that only lives in Solr. What usually takes much longer > is to develop it first in Solr, then after the release was made refactor it > and move it to a module, with the burden of having to maintain > backwards-compatibility with the original implementation. IMO, this is up to the contributor. If a contributor wants to implement join for solr and not as a module, great. In many respects that can be easier. There are tradeoffs. Mandating one thing or another is a mistake. If someone wants to do it the other way, great too. Users benefit in both cases and I am happy. - Mark Miller lucidimagination.com Lucene/Solr User Conference May 25-26, San Francisco www.lucenerevolution.org
