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
