If we were starting from scratch, i'd agree with you that having a single Jira project makes more sense, but given where we are today, i think we should probably keep them distinct -- partly from a "pain of migration" standpoint on our end, but also from a user expecations standpoint -- i think the Solr users/community as a whole is use to the existence of the SOLR project in Jira, and use to the SOLR-* issue naming convention, and it would likely be more confusing for *them* to change now.
: * With modules, we now have components in the Lucene JIRA project for : different modules (some under modules/* some under lucene/contrib/*). Will : we have the same components duplication in the Solr JIRA project? when we discussed this before, it seemed clear that top level modules should be tracked as LUCENE issues, so i see no reason why there would be duplications. : * Where do users go to open a bug report for a module - Lucene or Solr : projects? I'd hate to see that they open it under their "favorite" (or : worse. random picking) project. If so, it'll become a mess. the user bases tend to be very distinct -- if people are dealing with the lucene java API directly they file a LUCENE bug, if they are dealing with the Solr HTTP or client layer (SolrJ) APIs they file a Solr bug. If an issue is filed in a place where we think it doesn't make sense, the issue can easily be moved (and Jira does a redirect for anyone following old links) : * Administration -- everything needs to be done twice. Create versions (same : one !) on both projects, close issues (after release) etc. given the low overhead of this, it doesn't seem all that problematic. : * Managing a release now means I should monitor two JIRA projects for the : 3.2 (an example) version issues. Why? Here's an example of a filter that shows you all issues marked to be fixed in 3.2 in both projects... https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=%28project+%3D+SOLR+OR+project+%3D+LUCENE%29+AND+fixVersion+%3D+%223.2%22+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC%2C+key+DESC%2C+priority+DESC : I guess I'm not too sure what do two JIRA projects give us. Now that it is : the same project, why not make our (committers and contributors) life easier Short answer: trade off "ease of use for committers + pain of migration" against "ease of use for users" ... doesn't seem like a strong need to change. : It's already becoming confusing: neither of these examples seem that confusing to me... : LUCENE-3097: post grouping faceting -- a great example for a module that : both Lucene and Solr users can use. Opened under Lucene project, and : depends on Solr issues (not a big deal) it's an issue for implementing a top level module, therforce it goes in LUCENE. it doesn't depend on any Solr issue, it's marked as being blocked by another issue about adding another top level module : LUCENE-3104: could easily have been opened under the Solr project. I : don't know why it was opened under Lucene (random maybe?) Because it's about improving the hudson build which operates at the top level of the tree -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
