lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <>
Subject Re: Porting questions
Date Thu, 01 May 2014 12:23:04 GMT


Itamar Syn-Hershko | @synhershko <>
Freelance Developer & Consultant
Author of RavenDB in Action <>

On Thu, May 1, 2014 at 9:42 AM, Simon Svensson <> wrote:

> 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/ (added remote as origin)
> 2) I've added another remote for apache/ 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/ Or are we pushing directly to apache/

The best way to work is by creating branch-per-feature or porting job or
whatever and then sending a PR to apache/ Then notify us in the
mailing list (or open a JIRA ticket, but I think discussions on the GitHub
repos are much easier to work with).

After discussions and possibly some revisions (by pushing more commits to
your branch) we can merge to branch_4x in upstream and once it will be
synced with the github mirror (it takes it 30 mins or so) the PR will be
automatically marked as closed.

> Q: Is the mirroring against the apache-hosted 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.)

Someone (I think Paul) removed them from the solution, and the work now is
on bringing them back in mostly by re-porting them

> 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.

Please read up on the mailing list and look at the most recent commits. We
are already doing that.

> // Simon

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message