[no subject]
http://synergy2000.net/components/com_ag_google_analytics2/google.html - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[no subject]
[no subject]
[no subject]
[no subject]
- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[no subject]
+1 (non-binding) Automated tests were happy for me -- SUCCESS! [1:16:35.519232] I ran a Java API compatibility check between 6.5.0 and this 6.5.1 and while there's a few changes, I don't think any of them would actually end up as user facing. Posted results at http://people.apache.org/~mdrob/lucene-6.5.1/ Mike - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[no subject]
BeastIt Unit Test Beasting Summary Report for Apache Solr Master BeastIt gives unit tests a chance to duke it out in a fair but difficult environment. Each test is beasted and then judged. See a link to the full reports below. Number of Tests: 1108 Number Passed: 1073 % Passed: 96.84% Ran 30 iterations, 5 at a time Markers (Marked tests have one of these markers) @AwaitsFix: 1 @BadApple: 13 @Ignore: 3 *** Worst Test - Not Marked (It's your Moby Dick!) - TestTriggerIntegration 33% screwy '' If you catch that whale, next try - TestReplicationHandler 30% unreliable '' *** New Test(s) Failing?! Sound the alarm, we may have a cowboy here. - LeaderVoteWaitTimeoutTest 3% flakey - ScheduledMaintenanceTriggerTest 23% unreliable *** New Failures in Test(s)?! Everything looked so good! - HdfsRecoveryZkTest 3% flakey was 0,0,0,0 - HdfsCollectionsAPIDistributedZkTest 3% flakey was 0,0,0,0 - HttpPartitionTest 3% flakey was 0,0,0,0 - TestRecovery 6% flakey was 0,0,0,0 - TestBulkSchemaAPI 3% flakey was 0,0,0,0 - SolrShardReporterTest 3% flakey was 0,0,0,0 - AutoScalingHandlerTest 3% flakey was 0,0,0,0 *** Slowest Test - CdcrReplicationDistributedZkTest 1728.84 unreliable '@BadApple @Nightly ' Can you speed me up? *** Worst Test - Marked (How long must it suffer the mark?) - TestLargeCluster 33% screwy '@BadApple ' *** Non Running Tests - Coverage Holes?! - ChaosMonkeyShardSplitTest '@Ignore ' - TestRankQueryPlugin '@Ignore ' - TestMailEntityProcessor '@Ignore ' Full Reports http://apache-solr.bitballoon.com (Report maintained by Mark Miller)
[no subject]
http://zarabiaj-internetowo.pl/wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/pinit.php?svhrws1721ezrx Qiang Zhou yczhouqi...@yahoo.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[no subject]
Hello to all users, contributors and Committers! The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for Community over Code EU 2024 are now open! We will be supporting Community over Code EU, Bratislava, Slovakia, June 3th - 5th, 2024. TAC exists to help those that would like to attend Community over Code events, but are unable to do so for financial reasons. For more info on this years applications and qualifying criteria, please visit the TAC website at < https://tac.apache.org/ >. Applications are already open on https://tac-apply.apache.org/, so don't delay! The Apache Travel Assistance Committee will only be accepting applications from those people that are able to attend the full event. Important: Applications close on Friday, March 1st, 2024. Applicants have until the the closing date above to submit their applications (which should contain as much supporting material as required to efficiently and accurately process their request), this will enable TAC to announce successful applications shortly afterwards. As usual, TAC expects to deal with a range of applications from a diverse range of backgrounds; therefore, we encourage (as always) anyone thinking about sending in an application to do so ASAP. For those that will need a Visa to enter the Country - we advise you apply now so that you have enough time in case of interview delays. So do not wait until you know if you have been accepted or not. We look forward to greeting many of you in Bratislava, Slovakia in June, 2024! Kind Regards, Gavin (On behalf of the Travel Assistance Committee)
[no subject]
[no subject]
[no subject]
Hello Folks, We have been using faceted search feature of lucene in our search application without the feature that lets you drill down on a facet dimension. With https://issues.apache.org/jira/browse/LUCENE-8367 you get the ability to skip indexing drill-down terms for top level dimension - '*foo*' for path '*foo/bar*'. However, a StringField still gets created for path *'foo/bar*' which will never be queried in our application wasting index space. Ideally we would like `o.a.l.f.FacetsConfig` to provide an option to skip indexing drill-down terms all together. I wonder if community has other ideas on this. Thanks -Ankur
