lucenenet-dev mailing list archives

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

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Thu, May 1, 2014 at 9:42 AM, Simon Svensson <sisve@devhost.se> 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/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"
>

yes


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

The best way to work is by creating branch-per-feature or porting job or
whatever and then sending a PR to apache/lucene.net. 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 lucene.net repository
> automatic?
>

Yes


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

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