lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Svensson <si...@devhost.se>
Subject Porting questions
Date Thu, 01 May 2014 06:42:27 GMT
Hi,

I've once again woken up thinking that I should stop lurking and start 
coding.

Could someone confirm that I am going about this in a correct way?
1) I've forked the repository to sisve/lucene.net (added remote as origin)
2) I've added another remote for apache/lucene.net named upstream
3) I'm using the branch named "branch_4x"

Q: Do we work by coding in our personal repos and sending pull request 
to apache/lucene.net? Or are we pushing directly to apache/lucene.net?
Q: Is the mirroring against the apache-hosted lucene.net repository 
automatic?

When opening the Lucene.Net.sln file, hosting only Lucene.Net, 
Lucene.Net.Tests and Lucene.Net.TestFramework, I have a suspiciously low 
number of tests, only 24 (of which 3 fails). (At least it compiles.)

Q: Am I doing something wrong, or is this the current state?

Since I've had some run-ins with the hunspell analyzer (a long long time 
ago) I thought that I should look into the contrib solution and see 
what's needed. I'm quickly informed by Resharper's solution-wide 
analysis "[n] errors in [m] files", where [n] and [m] > 0.

I'm thinking that the first step is to introduce a big 
PortingHelper.cs-file with extension methods matching the java api, 
forward them to the correct .net api (usually just casing- or minor 
changes), and marking these helper extension methods as obsolete. This 
would both allow stuff to compile, and give hints to whoever ports/fixes 
the classes about the ".net way" to do whatever is being done. This 
PortingHelper.cs-file should not be present when we're done (doh!).

Q: Does this seem reasonable? The goal is to make everything compile 
(even with obsolete-warnings) so that the tests can tell the status of 
things.

// Simon


Mime
View raw message