[
https://issues.apache.org/jira/browse/SOLR-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1811:
-
Attachment: SOLR-1811.patch
> DataImportHandler: dataimporter.functions.formatDate should have a redefined
[
https://issues.apache.org/jira/browse/SOLR-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846750#action_12846750
]
Noble Paul commented on SOLR-1811:
--
I guess I got it. I am reusing the DatemathParser insta
[
https://issues.apache.org/jira/browse/SOLR-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846747#action_12846747
]
Yonik Seeley commented on SOLR-1830:
Adding
to the example solrconfig.xml seems to wo
tests should be able to use RAMDirectory
Key: SOLR-1830
URL: https://issues.apache.org/jira/browse/SOLR-1830
Project: Solr
Issue Type: Improvement
Reporter: Yonik Seeley
Priori
On Wed, Mar 17, 2010 at 8:15 PM, Chris Hostetter
wrote:
>
> My key point being: Version numbers should communicate the
> significance in change to the *user* of the product, and the users of
> Solr are differnet then the users of Lucene-Java, so even if the releases
> happen in lock step, that doe
[
https://issues.apache.org/jira/browse/SOLR-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846732#action_12846732
]
Yonik Seeley commented on SOLR-1379:
Thanks Alex! I've committed this on branches/newtr
Hi All,
>
>
> : In the interest of moving forward, perhaps we should just focus on the
> : immediate next major release - 3.1. What happens after can wait. We
> : never planned for absolutely all the "what if's" in Solr before the
> : merge - I'm not sure why we would need to now.
>
> I suppo
[
https://issues.apache.org/jira/browse/SOLR-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846730#action_12846730
]
Yonik Seeley commented on SOLR-1379:
Haha - I just write almost the exact same RAMDirect
[
https://issues.apache.org/jira/browse/SOLR-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846725#action_12846725
]
Yonik Seeley commented on SOLR-1553:
Hmmm, the intention was to try and detect when a ':
On Wed, Mar 17, 2010 at 9:16 PM, Grant Ingersoll wrote:
> I tend to agree w/ Hoss here. I don't think we have to be the same version
> numbers and I don't think we absolutely have to do lockstep releases.
No one said "absolutely".
It's important to try and release at the same time. Without th
I tend to agree w/ Hoss here. I don't think we have to be the same version
numbers and I don't think we absolutely have to do lockstep releases.
On Mar 17, 2010, at 8:38 PM, Chris Hostetter wrote:
>
> : In the interest of moving forward, perhaps we should just focus on the
> : immediate next
: In the interest of moving forward, perhaps we should just focus on the
: immediate next major release - 3.1. What happens after can wait. We
: never planned for absolutely all the "what if's" in Solr before the
: merge - I'm not sure why we would need to now.
I suppose, but if we call the nex
: Okay, so this looks good to me (a few others seemed to like it - though
: Lucene-Dev was somehow dropped earlier) - lets try this out on the branch?
It's the hassle of cross posting, really easy for someone to not reply to
all (especailly since i think all of the ASF lists rewrite the Reply-To
On Wed, Mar 17, 2010 at 8:15 PM, Chris Hostetter
wrote:
>
> : > No, actaully it's the converse issue -- if a major piece moves from "solr"
> : > to "core" and a *person* wanted to make a major change to that piece of
> : > functionality that wasn't backwards compatible, then "core" would
> : > cer
: > No, actaully it's the converse issue -- if a major piece moves from "solr"
: > to "core" and a *person* wanted to make a major change to that piece of
: > functionality that wasn't backwards compatible, then "core" would
: > certianly need to undergo a major version bump.
:
: To try and put i
[
https://issues.apache.org/jira/browse/SOLR-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uri Boness updated SOLR-1829:
-
Attachment: SOLR-1829.patch
this patch uses jquery to generate the proper requests to the field analysis
Cleaned up analysis.jsp - removed all token API scriptlets
--
Key: SOLR-1829
URL: https://issues.apache.org/jira/browse/SOLR-1829
Project: Solr
Issue Type: Improvement
Compone
On 03/17/2010 12:46 PM, Robert Muir wrote:
On Wed, Mar 17, 2010 at 12:40 PM, Mark Miller wrote:
Okay, so this looks good to me (a few others seemed to like it - though
Lucene-Dev was somehow dropped earlier) - lets try this out on the branch?
(then we can get rid of that "horrible" branch n
On Wed, Mar 17, 2010 at 12:40 PM, Mark Miller wrote:
> Okay, so this looks good to me (a few others seemed to like it - though
> Lucene-Dev was somehow dropped earlier) - lets try this out on the branch?
> (then we can get rid of that "horrible" branch name ;) )
>
> Anyone on the current branch ob
Okay, so this looks good to me (a few others seemed to like it - though
Lucene-Dev was somehow dropped earlier) - lets try this out on the
branch? (then we can get rid of that "horrible" branch name ;) )
Anyone on the current branch object to having to do a quick svn switch?
On 03/16/2010 06:4
On Wed, Mar 17, 2010 at 9:09 AM, Michael McCandless
wrote:
> Git, Maven, Hg, etc., all sound great for the future, but let's focus
> now on the baby step (how to re-org svn), today, so we can land the
> Solr upgrade work now being done on a branch...
>
I agree.
Another thing anyone can do to hel
Git, Maven, Hg, etc., all sound great for the future, but let's focus
now on the baby step (how to re-org svn), today, so we can land the
Solr upgrade work now being done on a branch...
Hoss's side-by-side proposal sounds great... and his concrete steps
"that could be done today" look good (I'm ho
+1 for this structure and this set of steps.
Otis
- Original Message
> From: Chris Hostetter
> To: solr-dev@lucene.apache.org
> Sent: Tue, March 16, 2010 6:46:19 PM
> Subject: Re: lucene and solr trunk
>
> : Otis, yes, I think so, eventually. But that's gonna take much more
> disc
23 matches
Mail list logo
