Hi Grant, >> >> +1 again and this is also one of my main objections to the proposal as it >> stands. Let the community decide who the committers are, and let each >> community decide what version of software it depends on. I'm not convinced >> that they are the same communities for that matter, and statements made >> earlier about Solr being the biggest user of Lucene(-java) may be true from >> a Lucene ecosystem perspective, but I disagree it's true (or even provable >> for that matter) from an external perspective given Lucene(-java)'s >> widespread use predating Solr as an Apache project, and Lucene's infection >> into other communities (e.g., PHP with Zend, etc.) > > So, when those projects donate themselves to Apache, we can manage them, until > then what we are proposing would have absolutely no effect on them. They'll > still get their Lucene JARs just like they always do.
Actually it will have a profound affect on them, as it'll define when, how, where and why they get those JARs as that is dictated by those that release and prepare them, the entity on the table that is being proposed to be merged. > I don't hear anyone > proposing to gut those projects. The fact is, Solr is managed by the Lucene > PMC and it is our responsibility to make sure we produce good software under > the ASF model. That doesn't mean we have to merge, but, there are a good > chunk of committers and others who feel some improvement on the current > situation is necessary. Moreover, many people want what is in Solr, but don't > ever work to keep it whole. So why does that require "merging" the projects in the way proposed? I'm sorry I still don't buy into that? Why do we need to merge the committers of both projects into 1? So Solr committers can touch Lucene code, and update it? If that's the case, then propose the set of Solr committers that should be Lucene committers and call a vote on that. Or, vice versa. That way you can gauge feedback from the community on whether or not those being voted on have made enough contribution to be approved in. That's the Apache way, as I understand it. > From a PMC perspective, that's not fair to Solr > even if it benefits Lucene and is perfectly "legal" and vice versa, so as a > PMC member I don't like that situation. Furthermore, as a committer on both > projects, I don't like the duplication of effort and I don't like having to > choose between the two when I know that my changes would benefit both > communities but am forced to do so solely on the arbitrary fact that way back > in 2006 when CNET donated Solr they said "Let's make this a subproject" > instead of saying "Let's make this a contrib/feature of Lucene". I often > choose Solr these days solely b/c it means I can get access to it sooner from > an end use perspective and nothing else. This is why I was suggesting that perhaps a new TLP might make sense then for Solr, or potentially even Lucene. Why not start there instead of this approach being proposed? If the Lucene(-java) committers and Solr committers want a shared project between them, based off of 2 existing ASF projects, in essence to merge the code base and ensure that both are aligned and not duplicated, propose that and let's vote on that. That's not what I'm hearing though. > > The fact is, the PMC is who releases software, not individual committers or > even individual subprojects. The fact that their is a Solr and a Lucene is > almost an arbitrary distinction, at least in the early days. Nowadays, it's > obviously grown, but it still is the PMC that releases both. Understood, I hear ya. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
