I'm still +1 for merging Solr/Lucene dev. I think poaching, when we have so much that needs to be shared, is going to cause far more problems than it'll solve. It's not the right tool for [this] job.
I do think poaching is good & legitimate tool when it's less code (eg the CommonGrams case), so, we should do both ;) Mike On Tue, Mar 9, 2010 at 8:49 AM, Grant Ingersoll <[email protected]> wrote: > > On Mar 9, 2010, at 8:21 AM, Michael McCandless wrote: > >> On Tue, Mar 9, 2010 at 7:21 AM, Grant Ingersoll <[email protected]> wrote: >> >>>> If we had that freedom ("poaching is perfectly fine"), then, >>>> interested devs could freely "refactor" across sub projects. >>> >>> As someone who works on both, I don't think it is fine. Just look at the >>> function query mess. Just look at the version mess. It's very frustrating >>> as a developer and it makes me choose between two projects that I happen to >>> like equally, but for different reasons. If I worked on Nutch, I would >>> feel the same way. >> >> But... Lucene should poach from external (eg non-Apache) projects, if >> the license works? >> >> Ie if some great analyzer is out there, and Robert spots it, and the >> license works, we should poach it? (In fact he just did this w/ >> Andrzej's Polish stemmer ;) ). > > I'd prefer "donate" to poach, but, realize that isn't always the case. > > >> >> So we have something of a double standard... >> >> And, ironically, I think it's the fact that there's so much committer >> overlap between Solr and Lucene that is causing this antagonism >> towards poaching. >> >> When in fact I think poaching, at a wider scale (across unrelated >> projects) is a very useful means for any healthy open source software >> to evolve. >> >> Why should Lucene be prevented from having a useful feature just >> because Solr happened to create it first? > > But why should I be forced to maintain two versions due to some arbitrary > code separation? And why should you force a good chunk of us to do a whole > lot of extra work simply because of some arbitrary code separation? Here, it > is the Lucene PMC that releases code and it is just silly that with all of > this overlap at the committer level we still have this duplication. I can't > speak for the external projects (I don't believe any of them have even > responded here other than Jackrabbit), but if they don't like it, they should > get more involved in the community and work to be committers. > > At any rate, this is exactly why merging makes sense. You would no longer > have this issue of "first". I would no longer have to choose where to add my > spatial work based on some arbitrary line that someone drew in the sand that > isn't all that pertinent anymore given the desires of most in the community > to blur that line. It would be available to everyone. > > For that matter, why do we even need to have this discussion at all? Most of > us Solr committers are Lucene committers. We can simply start committing > Solr code to Lucene such that in 6 months the whole discussion is moot and > the three committers on Solr who aren't Lucene committers can earn their > Lucene merit very quickly by patching the "Solr" portion of Lucene. We can > move all the code to it's appropriate place, add a contrib module for the WAR > stuff and the response writers and voila, Solr is in Lucene, the dev mailing > lists have merged by the fact that Solr dev would be defunct and all of the > proposals in this vote are implemented simply by employing our commit > privileges in a concerted way. Yet, somehow, me thinks that isn't a good > solution either, right? Yet it is perfectly "legal" and is just as valid a > solution as the "poaching" solution and in a lot of ways seems to be what > Chris is proposing. > > -Grant > > > > > > >
