lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Lucene/Solr JIRA
Date Wed, 18 May 2011 20:38:49 GMT
: I didn't know that it was decided that top-level modules issues go under the
: Lucene project. That indeed reduces some of the confusion (as long as users
: will adhere to it, but I guess it's also up to us to enforce it).

And as noted: "moving" a Jira issue from SOLR->LUCENE (or vice versa) is 
really simple with teh current version of Jira ... almost as easy as 
changing "Component"

: I think that one day we will need to merge. The more modules we'll have, the
: less issues will be open under Solr project (if it uses those modules). I
: agree w/ what Simon wrote - users will get used to it, so that's not a good
: reason IMO. Also, if we keep claiming the user base is different, then I
: think we have a problem ... every Solr user is also a Lucene user
: (eventually) -- true, some only interact w/ Solr REST API, and may not
: know/care Lucene is run at the lower level. But for the community's sake, I
: think merging JIRA will only help down the road.

I just don't see it that way ... saying every Solr user is also a Lucene 
user is like saying ever Solr user is a Java user, or every Solr user is a 
commons-io user ... we don't expect our users to know even know that, let 
alone assume that Solr users should know what layer of the stack a bug/feature 
should be filed against. 

If a Solr user has an issue/improvement at the Solr level of the stack 
they file a SOLR issue -- if they are a savy dev and know that the only 
real change is at the Lucene level they file a LUCENE issue, if we feel 
like we need to move a SOLR issue to a LUCENE issue we can do so, if we 
feel like there should be two issus to track the bug/change, one covering the 
Solr layer changes and one covering some dependent Lucene layer change we 
can do that to -- just like we could if someone filed a bug against a 
module component and we decided there was a dependent, but fundementally 
distinct core change that we wanted to track as a distinct jira.

: At the end of the day, I don't think we can maintain two projects for much
: longer, and I don't think it's the right thing to do at all. And if one day
: we'll merge JIRA projects, then tomorrow is as good a day as any other day.

We are one "Apache project", two "Apache Products".  The fact that the 
Jira terminology is "Project" is an implementation detail.

If we get to the point where we decide that we want to release some 
module as distinct release artifacts, because we think it has a distinct 
user community who doesn't know/care about the Lucene Core as a whole, 
then I would totally argue in favor of that module having a distinct Jira 
Product/Project as well.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message