You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2008/08/05 21:46:26 UTC
[VOTE] Set Solr 1.3 freeze and release date
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
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Henrib <hb...@gmail.com>.
>> SOLR-545: Remove Default core in multicore. No patch available.
Not sure how much should be added to this - I've added comment in the issue
itself.
>> SOLR-646: Config. props in multicore.xml Seems really useful, but is
currently unassigned.
Feel free to bug me as much as needed if I can help.
>> 0. Accept no more issues outside of this list, other than blockers
for 1.3.
+1
>> 1. Set August 12 as code freeze date. 1 week from today.
+1
>> I volunteer to be the release manager, unless someone else is dying to
do it.
Thanks!
--
View this message in context: http://www.nabble.com/-VOTE--Set-Solr-1.3-freeze-and-release-date-tp18838552p18841585.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Henrib <hb...@gmail.com>.
Grant Ingersoll-6 wrote:
>
>
> 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
>
>
The URL shows 12 now but solr-647 has no assignee yet.
May be Ryan since this can also occur "playing" with multicore in swap/close
conditions?
( Sorry Ryan :-) )
--
View this message in context: http://www.nabble.com/-VOTE--Set-Solr-1.3-freeze-and-release-date-tp18838552p18856909.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
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?
Finally! (I'm of the "release early, release often" philosophy myself)
> 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
I'm adding SOLR-513 assigned to me to get done by our cut-off date.
I've applied the patch locally, and will work through the
SolrDispatchFilter pathPrefix issue and commit when all is well.
> SOLR-545: Remove Default core in multicore. No patch available.
+1 - thanks Ryan!
> SOLR-506: Enabling HTTP Cache Headers should be configurable.
> Sounds ready to commit, right Shalin?
+1
> SOLR-646: Config. props in multicore.xml Seems really useful, but
> is currently unassigned.
>
> SOLR-614: Allow components to read any kind of XML. Has a couple of
> -1 on it that have been changed to -0
These two give me pause, not because they aren't clever and useful,
but rather it pains me to see Solr take on so much config. management
duties. It's a "code smell" to me to have a search engine be
concerning itself deeply with configuration.
But in general these are indeed handy additions, provided they aren't
abused.
> SOLR-619: Dynamic copyField at runtime. Rumor has it's completed...
Could the use case for this be explained? Why copyFields and not any
other piece of config/schema?
> 0. Accept no more issues outside of this list, other than blockers
> for 1.3.
Let me add SOLR-513, and if for some reason it doesn't make it in, no
big deal, but it'll be do-able by August 12.
> 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.
+1
> 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.
+1
> 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.
Thanks Grant for the prod! Solr 1.3 here we come!
Erik
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Grant Ingersoll <gs...@apache.org>.
On Aug 6, 2008, at 1:16 AM, Shalin Shekhar Mangar wrote:
> On Wed, Aug 6, 2008 at 1:16 AM, Grant Ingersoll
> <gs...@apache.org> 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?
>>
>
> +101 :)
>
>
>> 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.
>
>
> I think the same. Will find some time look into it.
>
>>
>>
>> SOLR-506: Enabling HTTP Cache Headers should be configurable.
>> Sounds
>> ready to commit, right Shalin?
>>
>
> Correct.
>
>>
>> SOLR-614: Allow components to read any kind of XML. Has a couple
>> of -1 on
>> it that have been changed to -0
>
>
> I'm very much +1 for it. Will review and commit soon.
Um, I don't know if committing is what is supposed to be done here.
There seems to be a general lack of enthusiasm for it, with several
-1's that were changed to -0, which is not exactly encouraging. My
gut says it should wait.
>
>
> 0. Accept no more issues outside of this list, other than blockers
> for 1.3.
>
>
> I'd like to add support for publishing artifacts to maven since it
> is very
> useful for a lot of people. We have 2 issues related to this.
> SOLR-19 and
> SOLR-586. However, it should not stop us from releasing 1.3
+1. I'd just copy what Lucene does.
>
>
>>
>> 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.
>
>
> +1 for August 12
>
> 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.
>
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
On Wed, Aug 6, 2008 at 1:16 AM, Grant Ingersoll <gs...@apache.org> 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?
>
+101 :)
> 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.
I think the same. Will find some time look into it.
>
>
> SOLR-506: Enabling HTTP Cache Headers should be configurable. Sounds
> ready to commit, right Shalin?
>
Correct.
>
> SOLR-614: Allow components to read any kind of XML. Has a couple of -1 on
> it that have been changed to -0
I'm very much +1 for it. Will review and commit soon.
0. Accept no more issues outside of this list, other than blockers for 1.3.
I'd like to add support for publishing artifacts to maven since it is very
useful for a lot of people. We have 2 issues related to this. SOLR-19 and
SOLR-586. However, it should not stop us from releasing 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.
+1 for August 12
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.
+1, however I feel there may be changes required in docs and builds.
Specifically, contrib build needs to be more consistent in terms of
manifests, clover.
Just one question, what are we going to do about the logo?
I volunteer to be the release manager, unless someone else is dying to do
> it.
Thank you!
--
Regards,
Shalin Shekhar Mangar.
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Dominic Mitchell <do...@semantico.com>.
On 6 Aug 2008, at 15:25, Erik Hatcher wrote:
> *ugh* - I'm on the fence on this one. I really think Solr should
> have release versions of Lucene JARs in its official releases.
> What to do? [go camping! see ya Saturday]
Is there any prospect of a Lucene release soon? Would that be good
fodder for a Solr 1.3.1 update?
-Dom
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Andrew Savory <as...@apache.org>.
Hi
2008/8/6 Erik Hatcher <er...@ehatchersolutions.com>:
> Practically speaking, though, Grant's right about the troubles it'd cause to
> roll back to the latest official Lucene release.
>
> *ugh* - I'm on the fence on this one. I really think Solr should have
> release versions of Lucene JARs in its official releases. What to do?
> [go camping! see ya Saturday]
I don't like the idea of rolling back since (a) it's undoing lots of
good work (b) it removes pressure on upstream (Lucene etc) to do new
releases. I'll try to look into all the upstreams later today and get
an idea of when releases might happen.
Enjoy the vacation!
Andrew.
--
asavory@apache.org / contact@andrewsavory.com
http://www.andrewsavory.com/
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Aug 6, 2008, at 6:37 AM, Andrew Savory wrote:
> There's also the issue of using snapshots
> (commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
> lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
> lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
> lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
> emphasis on the legal issues surrounding the use of snapshots, I'd
> suggest we should ship 1.3 with latest stable releases of those
> dependencies.
Andrew - I'm mostly with you on this myself, primarily from the
dependency sanity issue, but also in the Lucene case of the
possibility that the index format could change and break Solr
backwards compatibility (or at least forcing the issue to be addressed
somehow).
I'm not sure what the situation with commons-csv - probably something
got fixed in trunk?
Practically speaking, though, Grant's right about the troubles it'd
cause to roll back to the latest official Lucene release.
*ugh* - I'm on the fence on this one. I really think Solr should have
release versions of Lucene JARs in its official releases. What to
do? [go camping! see ya Saturday]
Erik
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Chris Hostetter <ho...@fucit.org>.
: I would strongly prefer a released version of Lucene. We made some changes
: to Solr 1.1 that required tweaks inside of Lucene, and it was quite a
: treasure hunt to a suitable set of Lucene source.
The precise source of all dependencies is identified in CHANGES.txt
(Hmmm... ok, aparently Grant didn't do that when he commited
SOLR-572/r669485 but it is recorded in the MANIFEST, and i will fix
CHANGES.txt)
: It just seems wrong for Solr to release a version of Lucene.
"Solr" doesn't release anything ... the Apache Lucene PMC releases Solr,
and Lucene-Java
-Hoss
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Walter Underwood <wu...@netflix.com>.
I would strongly prefer a released version of Lucene. We made some changes
to Solr 1.1 that required tweaks inside of Lucene, and it was quite a
treasure hunt to a suitable set of Lucene source.
It just seems wrong for Solr to release a version of Lucene.
wunder
On 8/6/08 8:53 AM, "Chris Hostetter" <ho...@fucit.org> wrote:
>
> : Yes, it's good that lots of Solr people are also Lucene people. But I
> : don't think that makes it alright to ship Lucene nightlies or
> : snapshots.
>
> Apache Lucene is a TLP, Apache Solr and Apache Lucene-Java are just
> individual products/sub-projects of that TLP.
>
> If the Apache Lucene PMC votes to release a particular bundle of source
> code as "Apache Solr 1.3" and that bundle includes source (or binary) code
> from the Lucene-Java subproject that hasn't already been released (via PMC
> vote) then it is by definition officially released Apache Lucene software.
>
> So in a nutshell: yes it is "alright for Solr to ship Lucene nightlies" --
> because once the PMC votes on that Solr release, it doesn't matter where
> that Lucene-Java jar came from, it's officially released code.
>
> I'm told there is even precedence for the PMC of a TLP X to vote
> and officially release code from completley seperate TLP Y because Y had
> not had a release and X was ready to go.
>
> Where dependencies on "snapshots" in official releases causes problems is
> when those snapshots are from third parties and/or are not reproducable --
> where the specific version of the dependencies is unknown and as a result
> the "dependee" can not be reproduced. We do not have that problem
> with any Apache codebase we have a dependency on. We know exactly which
> svn revision the dependencies come from, and since the SVN repository is
> public, anyone can recreate it.
>
>
> -Hoss
>
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Chris Hostetter <ho...@fucit.org>.
: Yes, it's good that lots of Solr people are also Lucene people. But I
: don't think that makes it alright to ship Lucene nightlies or
: snapshots.
Apache Lucene is a TLP, Apache Solr and Apache Lucene-Java are just
individual products/sub-projects of that TLP.
If the Apache Lucene PMC votes to release a particular bundle of source
code as "Apache Solr 1.3" and that bundle includes source (or binary) code
from the Lucene-Java subproject that hasn't already been released (via PMC
vote) then it is by definition officially released Apache Lucene software.
So in a nutshell: yes it is "alright for Solr to ship Lucene nightlies" --
because once the PMC votes on that Solr release, it doesn't matter where
that Lucene-Java jar came from, it's officially released code.
I'm told there is even precedence for the PMC of a TLP X to vote
and officially release code from completley seperate TLP Y because Y had
not had a release and X was ready to go.
Where dependencies on "snapshots" in official releases causes problems is
when those snapshots are from third parties and/or are not reproducable --
where the specific version of the dependencies is unknown and as a result
the "dependee" can not be reproduced. We do not have that problem
with any Apache codebase we have a dependency on. We know exactly which
svn revision the dependencies come from, and since the SVN repository is
public, anyone can recreate it.
-Hoss
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Mark Miller <ma...@gmail.com>.
Andrew Savory wrote:
> It sucks to delay Solr 1.3, but perhaps we should all hope over to the
> Lucene mailing lists and start pushing for a stable release there?
>
A while back (a year now or a i bit less i think) there was a push for
doing Lucene releases much more often. It didn't work out IMO :) But it
was well supported in discussion - probably worth bringing up again.
- Mark
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Andrew Savory <as...@apache.org>.
Hi,
2008/8/6 Grant Ingersoll <gs...@apache.org>:
> I'm less concerned about Lucene, but maybe that's b/c I live close to it.
> Taking it out would mean a decent amount of rolling back. We will almost
> certainly have a 1.3.1 release, etc. unless all goes swimmingly.
Yes, it's good that lots of Solr people are also Lucene people. But I
don't think that makes it alright to ship Lucene nightlies or
snapshots.
One of the reasons projects are pushed into doing releases is because
of pressure from downstream projects who need stable releases for
their own code. Therefore Solr should be gently exerting pressure on
Lucene to do a stable release, in just the same way that some of us
who depend on Solr are exerting pressure for a Solr release.
If you short-circuit that process by saying "well, we know lucene so
it's ok for us to use unstable builds", then there might never be a
stable release of Lucene again (hyperbole and exaggeration, but you
get my point).
Another reason: say corporation X has a policy to use "only released
software" (lots do). Developers at X could grab Solr 1.3 and use it
without problem, but what if they were building a supercool tool Y
that worked alongside Solr, but used only Lucene libraries. Clearly
they would want to use the latest library, but they would be forced to
only use the release, which practically guarantees headaches and
interoperability problems between Solr and tool Y.
It sucks to delay Solr 1.3, but perhaps we should all hope over to the
Lucene mailing lists and start pushing for a stable release there?
> Also, note 1.2 has Lucene dev JARs in it, not official releases...
And had I been around when 1.2 was released, I'd have made the same
arguments ;-)
Andrew.
--
asavory@apache.org / contact@andrewsavory.com
http://www.andrewsavory.com/
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Grant Ingersoll <gs...@apache.org>.
On Aug 6, 2008, at 7:47 AM, Guillaume Smet wrote:
> On Wed, Aug 6, 2008 at 12:37 PM, Andrew Savory <as...@apache.org>
> wrote:
>> There's also the issue of using snapshots
>> (commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
>> lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
>> lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
>> lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
>> emphasis on the legal issues surrounding the use of snapshots, I'd
>> suggest we should ship 1.3 with latest stable releases of those
>> dependencies.
>
> Yes, I'm kinda annoyed too with lucene 2.4-dev integration in a stable
> release. What if a bug is fixed in Lucene after the release and we
> cannot package 2.4-dev trunk because it has too many changes (physical
> format changes, API changes...)? Is Solr dev team going to maintain a
> separate branch with the 2.4-dev snapshot version shipped with 1.3 +
> bugfixes?
I'm less concerned about Lucene, but maybe that's b/c I live close to
it.
Taking it out would mean a decent amount of rolling back. We will
almost certainly have a 1.3.1 release, etc. unless all goes swimmingly.
Also, note 1.2 has Lucene dev JARs in it, not official releases...
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Guillaume Smet <gu...@gmail.com>.
On Wed, Aug 6, 2008 at 12:37 PM, Andrew Savory <as...@apache.org> wrote:
> There's also the issue of using snapshots
> (commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
> lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
> lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
> lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
> emphasis on the legal issues surrounding the use of snapshots, I'd
> suggest we should ship 1.3 with latest stable releases of those
> dependencies.
Yes, I'm kinda annoyed too with lucene 2.4-dev integration in a stable
release. What if a bug is fixed in Lucene after the release and we
cannot package 2.4-dev trunk because it has too many changes (physical
format changes, API changes...)? Is Solr dev team going to maintain a
separate branch with the 2.4-dev snapshot version shipped with 1.3 +
bugfixes?
--
Guillaume
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Norberto Meijome <fr...@meijome.net>.
On Wed, 6 Aug 2008 07:35:47 -0400
Grant Ingersoll <gs...@apache.org> wrote:
> > I'd like to see the following issues added to the list (in order of
> > priority):
> >
> > https://issues.apache.org/jira/browse/SOLR-84 New logo
>
> I think we should hold off on the logo. I'm more of the mindset now
> that we can do better.
emphatic +1.
>
> >
> > https://issues.apache.org/jira/browse/SOLR-76 New admin pages (see
> > also https://issues.apache.org/jira/browse/SOLR-643)
>
> Given I personally don't think the logo is good enough, I don't see
> too much pointing in updating the admin pages either.
yup. candidate for a 1.3.5 (1.3.1., 1.4 , whatever ) , with other smaller things that may be ready in when these are too...?
_________________________
{Beto|Norberto|Numard} Meijome
"Build a system that even a fool can use, and only a fool will want to use it."
George Bernard Shaw
I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned.
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Ryan McKinley <ry...@gmail.com>.
>>
> If people decide to wait and accept more logos, why not have a proper
> logo contest as other projects have done... let everyone know that new
> logo candidates are being accepted.
+1
hopefully solr is at a scale where a standard logo contest would draw
a few good entries
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Yonik Seeley <yo...@apache.org>.
On Wed, Aug 6, 2008 at 7:58 AM, Mark Miller <ma...@gmail.com> wrote:
>> I think we should hold off on the logo. I'm more of the mindset now that
>> we can do better.
>
> I think this is a great idea - hopefully. The interest by a couple guys to
> submit more logos is awesome - I just hope holding off won't drop everything
> off the radar. Someone mentioned all this hubbub happening before, and then
> nothing was done.
Seems to be moving in that direction this time too :-)
> We ran two polls as well, and we are throwing that all
> away - I still think its a good idea to wait if we are actually going to get
> more logos though - we certainly don't want to be changing it on every
> release, so I think we want to be relatively happy with it.
If people decide to wait and accept more logos, why not have a proper
logo contest as other projects have done... let everyone know that new
logo candidates are being accepted.
-Yonik
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Mark Miller <ma...@gmail.com>.
>>
>>> So, what to vote on?
>>>
>>> 0. Accept no more issues outside of this list, other than blockers
>>> for 1.3.
>>
>> I'd like to see the following issues added to the list (in order of
>> priority):
>>
>> https://issues.apache.org/jira/browse/SOLR-84 New logo
>
> I think we should hold off on the logo. I'm more of the mindset now
> that we can do better.
I think this is a great idea - hopefully. The interest by a couple guys
to submit more logos is awesome - I just hope holding off won't drop
everything off the radar. Someone mentioned all this hubbub happening
before, and then nothing was done. We ran two polls as well, and we are
throwing that all away - I still think its a good idea to wait if we are
actually going to get more logos though - we certainly don't want to be
changing it on every release, so I think we want to be relatively happy
with it.
>
>>
>> https://issues.apache.org/jira/browse/SOLR-76 New admin pages (see
>> also https://issues.apache.org/jira/browse/SOLR-643)
>
> Given I personally don't think the logo is good enough, I don't see
> too much pointing in updating the admin pages either.
I don't think there has been enough work here yet anyway. And like the
logo, we are going to have to make sure its the direction that the
majority wants to go. Users definitely want a more professional look at
some point - but I think these issues are more starting points.
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Grant Ingersoll <gs...@apache.org>.
On Aug 6, 2008, at 6:37 AM, Andrew Savory wrote:
> Hi,
>
> 2008/8/5 Grant Ingersoll <gs...@apache.org>:
>
>> So, what to vote on?
>>
>> 0. Accept no more issues outside of this list, other than blockers
>> for 1.3.
>
> I'd like to see the following issues added to the list (in order of
> priority):
>
> https://issues.apache.org/jira/browse/SOLR-84 New logo
I think we should hold off on the logo. I'm more of the mindset now
that we can do better.
>
> https://issues.apache.org/jira/browse/SOLR-76 New admin pages (see
> also https://issues.apache.org/jira/browse/SOLR-643)
Given I personally don't think the logo is good enough, I don't see
too much pointing in updating the admin pages either.
>
> https://issues.apache.org/jira/browse/SOLR-484 Solr Website changes
This is going forward regardless of release.
>
> https://issues.apache.org/jira/browse/SOLR-19 pom.xml to support
> maven2
Sounds like Shalin has taken this up.
>
>
> None of these are particularly crucial from a codebase perspective,
> but I believe all of them are crucial from a community perspective.
>
>> 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.
>
> Non-binding +1.
>
>> 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.
>
> Non-binding +1.
>
>> I volunteer to be the release manager, unless someone else is dying
>> to do
>> it.
>
> Non-binding +1.
>
>
> There's also the issue of using snapshots
> (commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
> lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
> lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
> lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
> emphasis on the legal issues surrounding the use of snapshots, I'd
> suggest we should ship 1.3 with latest stable releases of those
> dependencies.
>
Well, Lucene 2.4 isn't going to be released anytime soon, so...
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Andrew Savory <as...@apache.org>.
Hi,
2008/8/5 Grant Ingersoll <gs...@apache.org>:
> So, what to vote on?
>
> 0. Accept no more issues outside of this list, other than blockers for 1.3.
I'd like to see the following issues added to the list (in order of priority):
https://issues.apache.org/jira/browse/SOLR-84 New logo
https://issues.apache.org/jira/browse/SOLR-76 New admin pages (see
also https://issues.apache.org/jira/browse/SOLR-643)
https://issues.apache.org/jira/browse/SOLR-484 Solr Website changes
https://issues.apache.org/jira/browse/SOLR-19 pom.xml to support maven2
None of these are particularly crucial from a codebase perspective,
but I believe all of them are crucial from a community perspective.
> 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.
Non-binding +1.
> 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.
Non-binding +1.
> I volunteer to be the release manager, unless someone else is dying to do
> it.
Non-binding +1.
There's also the issue of using snapshots
(commons-csv-1.0-SNAPSHOT-r609327.jar, lucene-analyzers-2.4-dev.jar,
lucene-core-2.4-dev.jar, lucene-highlighter-2.4-dev.jar,
lucene-queries-2.4-dev.jar, lucene-snowball-2.4-dev.jar,
lucene-spellchecker-2.4-dev.jar, stax-1.2.0-dev.jar). Given recent
emphasis on the legal issues surrounding the use of snapshots, I'd
suggest we should ship 1.3 with latest stable releases of those
dependencies.
Andrew.
--
asavory@apache.org / contact@andrewsavory.com
http://www.andrewsavory.com/
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
SOLR-695 seems to be a move in the right direction. Now that Multicore
is renamed to CoreContainer it should not confuse anyone. The
reloadCore() should be a method in CoreContainer not CoreDescriptor .
On Wed, Aug 13, 2008 at 9:13 PM, Ryan McKinley <ry...@gmail.com> wrote:
>>>
>>>>
>>>> * A CoreDescriptor taking a null multicore instance is fine because
>>>> there is no multicore at all.
>>>
>>> Then we should, at a minimum, add a no-arg constructor, or at least
>>> document
>>> it can take null. Maybe then the name of the class is wrong. Class
>>> names
>>> are meaningful. And the name CoreDescriptor doesn't strike me as the
>>> place
>>> to hold Multicore. Overall, however, this reeks of the bigger problem in
>>> that we treat 1 core as a special case instead of it being Multicore with
>>> only a single core.
>>
>
> In SOLR-695, all Cores (and CoreDescriptors) will require a valid
> CoreContainer (MultiCore) -- passing null will not be an option.
>
> ryan
>
--
--Noble Paul
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Ryan McKinley <ry...@gmail.com>.
>>
>>>
>>> * A CoreDescriptor taking a null multicore instance is fine because
>>> there is no multicore at all.
>>
>> Then we should, at a minimum, add a no-arg constructor, or at least
>> document
>> it can take null. Maybe then the name of the class is wrong.
>> Class names
>> are meaningful. And the name CoreDescriptor doesn't strike me as
>> the place
>> to hold Multicore. Overall, however, this reeks of the bigger
>> problem in
>> that we treat 1 core as a special case instead of it being
>> Multicore with
>> only a single core.
>
In SOLR-695, all Cores (and CoreDescriptors) will require a valid
CoreContainer (MultiCore) -- passing null will not be an option.
ryan
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
On Wed, Aug 13, 2008 at 6:22 PM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Aug 13, 2008, at 12:07 AM, Noble Paul നോബിള് नोब्ळ् wrote:
>
>> On Tue, Aug 12, 2008 at 8:39 PM, Grant Ingersoll <gs...@apache.org>
>> 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)
>
> That doesn't make it right. The name of the class implies it describes the
> core, not the Multicore.
>
>>
>> * 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.
>
> I'll go review the archives, but it doesn't make sense to me. If anything,
> the singleCoreDescriptor could just be injected into Multicore in the case
> where it is the only core.
>
>
>>
>> * A CoreDescriptor taking a null multicore instance is fine because
>> there is no multicore at all.
>
> Then we should, at a minimum, add a no-arg constructor, or at least document
> it can take null. Maybe then the name of the class is wrong. Class names
> are meaningful. And the name CoreDescriptor doesn't strike me as the place
> to hold Multicore. Overall, however, this reeks of the bigger problem in
> that we treat 1 core as a special case instead of it being Multicore with
> only a single core.
There is a relationship of 1:n between a MultiCore and CoreDescriptor.
CoreDescriptor holding a reference to MultiCore is holding a reference
to the container like RequestHandlers/SolrIndexSearchers holding a
reference to SolrCore
>
> -Grant
--
--Noble Paul
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Grant Ingersoll <gs...@apache.org>.
On Aug 13, 2008, at 12:07 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
> On Tue, Aug 12, 2008 at 8:39 PM, Grant Ingersoll
> <gs...@apache.org> 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)
That doesn't make it right. The name of the class implies it
describes the core, not the Multicore.
>
> * 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.
I'll go review the archives, but it doesn't make sense to me. If
anything, the singleCoreDescriptor could just be injected into
Multicore in the case where it is the only core.
>
> * A CoreDescriptor taking a null multicore instance is fine because
> there is no multicore at all.
Then we should, at a minimum, add a no-arg constructor, or at least
document it can take null. Maybe then the name of the class is
wrong. Class names are meaningful. And the name CoreDescriptor
doesn't strike me as the place to hold Multicore. Overall, however,
this reeks of the bigger problem in that we treat 1 core as a special
case instead of it being Multicore with only a single core.
-Grant
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
On Tue, Aug 12, 2008 at 8:39 PM, Grant Ingersoll <gs...@apache.org> 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
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Grant Ingersoll <gs...@apache.org>.
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.
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
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Ryan McKinley <ry...@squid-labs.com>.
>
> SOLR-545: Remove Default core in multicore. No patch available.
>
> SOLR-646: Config. props in multicore.xml Seems really useful, but
> is currently unassigned.
>
I'm on these guys.
>
> 0. Accept no more issues outside of this list, other than blockers
> for 1.3.
+1
>
> 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.
+1
>
> 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.
>
+1
> 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.
thanks!
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Grant Ingersoll <gs...@apache.org>.
On Aug 6, 2008, at 1:00 AM, Chris Hostetter wrote:
> : 2. Code Freeze in effect for 5 days for testing of release
> candidates.
>
> +0 ... I'd prefer we spend more then 5 days on this. Both because i
> think
> we're missing a lot of docs; and because i have a hunch that when we
> really start shaking the tree, a lot of weird release packaging
> quirks/questions are going to fall out since this is the first
> release to
> include SolrJ and contribs.
>
> But I ain't going to stop you from cutting release candidates :)
>
We can go 7 or 10 days if you want. My experience in Lucene land is
that only 1 or 2 committers ever step up to the plate on the
documentation, but I do agree about the packaging stuff. How about we
aim for 5 days, and we'll be happy w/ 7?
Re: [VOTE] Set Solr 1.3 freeze and release date
Posted by Chris Hostetter <ho...@fucit.org>.
: 0. Accept no more issues outside of this list, other than blockers for 1.3.
+1
: 1. Set August 12 as code freeze date. 1 week from today. After which, only
+1
: 2. Code Freeze in effect for 5 days for testing of release candidates.
+0 ... I'd prefer we spend more then 5 days on this. Both because i think
we're missing a lot of docs; and because i have a hunch that when we
really start shaking the tree, a lot of weird release packaging
quirks/questions are going to fall out since this is the first release to
include SolrJ and contribs.
But I ain't going to stop you from cutting release candidates :)
-Hoss