On Tue, Aug 12, 2008 at 8:39 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > So, even though this passed in terms of votes, I don't have a real strong > sense that we are "there" yet. > > I especially feel queasy about the multicore stuff and worry about putting > that into stone, so to speak. I guess I don't get why a single core is not > just multicore w/ one core. For back compatibility, if multicore.xml is > not there, then we know to use a default one. We also have a single > CoreDescriptor to handle the single case, but the CoreDescriptor constructor > takes in a Multicore, so we abuse that and pass in null. I'm not sure why > a CoreDescriptor needs to have a ref. to the Multicore to begin with. It > doesn't seem to be used internally. * We need a reference to multicore in CoreDescriptor because that is a simple way to get a reference to the multicore rather than doing a MultiCore.getInstance() (SOLR-638) * The question of should the single core be a multicore w/ one core has been debated over and over and somehow we have decided that this is best compromise we can do for backward compatibility. A lot of users do not care about multicore and still go with the plain vanilla single core deployment. * A CoreDescriptor taking a null multicore instance is fine because there is no multicore at all.
> > So, as much as I would like to have a release, I don't think we should. > > On Aug 5, 2008, at 3:46 PM, Grant Ingersoll wrote: > >> Well, we've been beating around the bush on 1.3 for a good amount of time >> now. How about we set a date and actually vote on it and thus make it >> pseudo-binding? >> >> I see that we have 13 issues: >> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310230&fixfor=12312486 >> >> SOLR-410: Review the ResponseBuilder class. My take is this can be >> closed. We've (Solr that is) been running w/ it for a while now. >> >> SOLR-545: Remove Default core in multicore. No patch available. >> >> SOLR-243: Create a hook to bring in custom IndexReaders. This patch made >> a lot of progress, but then seems to be abandoned once unit tests were asked >> for. I suggest moving to 1.4 >> >> SOLR-624: Don't take snapshot if no diffs. Sounds ready to be committed >> >> SOLR-630: Spellchecker should not be case-sensitive and should be >> stopwords aware. No patch available or unit tests. Seems like it could be >> handled through analysis, but not sure. >> >> SOLR-506: Enabling HTTP Cache Headers should be configurable. Sounds >> ready to commit, right Shalin? >> >> SOLR-653: remove overwrite command. Sounds ready to commit >> >> SOLR-474: Audit docs for spellchecker Mike Klaas says he will take care of >> it. >> >> SOLR-646: Config. props in multicore.xml Seems really useful, but is >> currently unassigned. >> >> SOLR-619: Dynamic copyField at runtime. Rumor has it's completed... >> >> SOLR-614: Allow components to read any kind of XML. Has a couple of -1 on >> it that have been changed to -0 >> >> SOLR-489: Add deprecation docs. Last updated on the 4th. Needs review >> and should go in >> >> So, what to vote on? >> >> 0. Accept no more issues outside of this list, other than blockers for >> 1.3. >> 1. Set August 12 as code freeze date. 1 week from today. After which, >> only doc changes and blockers are allowed. So, if the above isn't fixed by >> then, it's out unless someone wants to make it a blocker. >> 2. Code Freeze in effect for 5 days for testing of release candidates. >> Thus, the 1.3 release, assuming all goes well will be on the 17th or 18th >> (since the 17th is a Sunday.) Thus SOLR-489 in theory need not be complete >> by the 12th, but the 18th instead, although we might as well get it done. >> >> What this means? Speak up now, unassign yourself, or otherwise "git 'r >> done" if you care about one of these issues. >> >> I volunteer to be the release manager, unless someone else is dying to do >> it. >> >> Cheers, >> Grant >> >> >> >> > > -------------------------- > Grant Ingersoll > http://www.lucidimagination.com > > Lucene Helpful Hints: > http://wiki.apache.org/lucene-java/BasicsOfPerformance > http://wiki.apache.org/lucene-java/LuceneFAQ > > > > > > > > -- --Noble Paul
