: prime-time as the new solr trunk!  Lucene and Solr need to move to a
: common trunk for a host of reasons, including single patches that can
: cover both, shared tags and branches, and shared test code w/o a test
: jar.

Without a clearer picture of how people envision development "overhead" 
working as we move forward, it's really hard to understand how any of 
these ideas make sense...
  1) how should hte automated build process(es) work?
  2) how are we going to do branching/tagging for releases?  particularly 
in situations where one product is ready for a rlease and hte other isn't?
  3) how are we going to deal with mino bug fix release tagging?
  4) should it be possible for people to check out Lucene-Java w/o 
checking out Solr?

(i suspect a whole lot of people who only care about the core library are 
going to really adamantly not want to have to check out all of Solr just 
to work on the core)

: Both projects move to a new trunk:
:   /something/trunk/java, /something/trunk/solr

by gut says something like this will more the most sense, assuming 
"/something/trunk" == "/java/trunk" and "java" actually means "core" ... 
ie: this discussion should really be part and parcel with how contribs 
should be reorged.



-Hoss

Reply via email to