Thanks for the update Itamar -- this sounds exciting. A few notes / questions from the build side of things here:
First, I'm not as hung up on persistently failing tests as the tests we get intermittent failures on. I suspect some of the below will address this. Second, what do we want to do about the 112 or so ignored tests? I think some are marked as long-running via the [LongRunningTest] attribute but there are probably some ignored failures in that mix. Third, regarding the sub-projects, what does the structure look like so I can get that integrated into the TeamCity setup? Or should I noodle on it and propose one? Thanks for all the help from everyone getting things this far. On Wed, Apr 8, 2015 at 1:07 PM, Itamar Syn-Hershko <[email protected]> wrote: > Hey all, > > We are nearly there -- we are this close to a release! > > We have only about 30 failing tests now in the core, and I'd like to push > hard during the next few days so we can get a beta out next week. > > I'd appreciate your help with this! > > I've narrowed down several failing tests that require some digging, if > folks can assign those to themselves and send us PRs fixing those tests, > that would help a lot! > > 1. Lucene.Net.Search.TestNumericRangeQuery32.TestInfiniteValues() > and Lucene.Net.Search.TestNumericRangeQuery64.TestInfiniteValues() -- > specifically it seems like Double and Float NaNs are treated differently > between C# and Java and therefore the failing tests. Or there is a bug in > the inner implementation handling those queries. > > 2. TestLucene40DocValuesFormat has a few failing tests, probably exposing > data corruption in one of the codec components. I believe this is contained > in the 40DocValues tests so the scope isn't huge but I could be wrong. > > 3. TestLucene42DocValuesFormat has two tests failing with output of lines > like "Fail: frozenHash=182658 vs h=5124052". Something is off in computing > the hashes of the nodes, or maybe the node construction is faulty (which is > a serious bug). Hashing is done in Lucene.Net.Fst.NodeHash<T>, that'll be a > good starting point. Also see > > https://github.com/apache/lucenenet/commit/ea7cfe6972972f91090d995c729689fff9a0f54c > > 4. There seem to be some concurrency issues with file handling, probably on > the part that is in charge of acquiring and releasing locks. In particular > see TestDocValuesFormat, > .TestShardSearching.TestSimple(), > TestBufferedIndexInput.TestSetBufferSize(), > TestLockFactory.TestStressLocks(), > TestLockFactory.TestStressLocksNativeFSLockFactory() > > 5. RegexpQuery seems to be broken, I believe the underlying automaton > implementation doesn't emit the terms correctly. See the failures in > TestRegexpQuery and TestRegexpRandom. > > 6. Similar but probably unrelated failing test is > at TestSpanMultiTermQueryWrapper.TestFuzzy2() > > 7. An interesting failure to investigate is here: > TestIndexableBinaryStringTools.TestEncodedSortability() -- probably a > simple porting fail, a subtle Java <--> C# mismatch that we haven't > noticed. > > Additionally, any help with porting the subprojects would be great. Some > folks took some subprojects under their wings and never reported back. If > you could either complete the work, or donate whatever you have done so > far, that would be great. > > As always, get the code from here: https://github.com/apache/lucenenet -- > work on your fork and send us a PR when ready, with a good description of > what you've done. > > To see the list of currently failing tests in real-time, go here (you can > login as guest): > > http://teamcity.codebetter.com/viewType.html?buildTypeId=LuceneNet_Core&branch_LuceneNet=%3Cdefault%3E&tab=buildTypeStatusDiv > > Thanks, and happy searching, > > -- > > Itamar Syn-Hershko > http://code972.com | @synhershko <https://twitter.com/synhershko> > Freelance Developer & Consultant > Lucene.NET committer and PMC member >
