You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Simon Svensson <si...@devhost.se> on 2014/05/01 08:42:27 UTC
Porting questions
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
Re: Porting questions
Posted by Itamar Syn-Hershko <it...@code972.com>.
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 Fri, May 2, 2014 at 8:58 PM, Simon Svensson <si...@devhost.se> wrote:
> That sounds like a Plugin of Pure Awesome.
>
> Anyhow, I've commited some stuff at https://github.com/sisve/
> lucene.net/commits/contrib-hunspell
>
> I changed the CharFilter to derive from TextReader instead of StreamReader
> and excluded tests from the Contrib.Test project, and everything that's
> still left compiles and pass the few tests that are present. There's one
> test for the core assembly which fails, looks like issues with
> RandomizedContext and testing infrastructure related.
>
> Q: Are the sources in Contrib/Contrib.Tests old 3.0.3-sources? Then my
> next step would be to port the 4.3.0 java-sources (for the hunspell code)
> before submitting a pull request.
>
Most of them, yes.
See my previous email on porting tests, generally it should now be mostly
copy-paste-minor fixes operation
>
> Q: The ICharTermAttribute lacks functionality for working with strings.
> This may be an issue due to previous question, the code I got running used
> String ITermAttribute.Term and not Char[]. Anyhow, should we add
> convenience methods to work with strings directly, or force callers to
> either with Char[] or do their own String.ToCharArray() calls?
This is a change on the Java part of things, for performance reasons, to
allow for in-place editing. You actually should keep it this way and port
the relevant changes made to the TokenFilter implementations
>
>
> // Simon
>
>
>
> On 01/05/14 22:02, Itamar Syn-Hershko wrote:
>
>> Yes, this is why we are working towards having a good R# plugin that will
>> let us do Java to C# porting easily, taking into account things like you
>> mention. This may already be supported by Paul's library by the way, and
>> if
>> it isn't it can certainly be added to it. The R# plugin we plan on having
>> will be based on that. I hope to have more news in the upcoming weeks.
>>
>> Personally I couldn't care less about curly brackets, but we should decide
>> on whitespaces/tabs and use stylecop or similar to enforce that, for
>> readability sake
>>
>> --
>>
>> 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 4:17 PM, Simon Svensson <si...@devhost.se> wrote:
>>
>> Outline!
>>>
>>> Regarding the extension methods mentioned at the end, I'm talking about
>>> introducing such a class/helper into the core Lucene.Net assembly for use
>>> of non-test assemblies. Those I've found so far (JavaCompatilibity/*.cs
>>> in
>>> Lucene.Test.Framework) are for tests only. Your mails from April 20th
>>> indicate that the purpose of such helper methods are for quick porting of
>>> tests only.
>>>
>>> One example would be the java substring function. I've been bitten
>>> several
>>> times (and never seem to learn) that the parameters are different between
>>> java and .net.
>>>
>>> [Obsolete("Call String.Substring instead. Note that Java uses
>>> start+end while .NET uses start+length")]
>>> public static String substring(this String value, Int32 start,
>>> Int32 end) {
>>> return value.Substring(start, end - start + 1);
>>> }
>>>
>>> On another line of thought, are there any code formatting rules or
>>> plugins
>>> that helps? I believe Resharper/StyleCop supports storing code formatting
>>> settings in a file that can be commited so we're producing similar
>>> looking
>>> code. Or should we start a religious war about curly braces and
>>> whitespaces? ;)
>>>
>>> // Simon
>>>
>>>
>>>
>>> On 01/05/14 14:23, Itamar Syn-Hershko wrote:
>>>
>>> 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 <si...@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
>>>>>
>>>>>
>>>>>
>>>>>
>
Re: Porting questions
Posted by Simon Svensson <si...@devhost.se>.
That sounds like a Plugin of Pure Awesome.
Anyhow, I've commited some stuff at
https://github.com/sisve/lucene.net/commits/contrib-hunspell
I changed the CharFilter to derive from TextReader instead of
StreamReader and excluded tests from the Contrib.Test project, and
everything that's still left compiles and pass the few tests that are
present. There's one test for the core assembly which fails, looks like
issues with RandomizedContext and testing infrastructure related.
Q: Are the sources in Contrib/Contrib.Tests old 3.0.3-sources? Then my
next step would be to port the 4.3.0 java-sources (for the hunspell
code) before submitting a pull request.
Q: The ICharTermAttribute lacks functionality for working with strings.
This may be an issue due to previous question, the code I got running
used String ITermAttribute.Term and not Char[]. Anyhow, should we add
convenience methods to work with strings directly, or force callers to
either with Char[] or do their own String.ToCharArray() calls?
// Simon
On 01/05/14 22:02, Itamar Syn-Hershko wrote:
> Yes, this is why we are working towards having a good R# plugin that will
> let us do Java to C# porting easily, taking into account things like you
> mention. This may already be supported by Paul's library by the way, and if
> it isn't it can certainly be added to it. The R# plugin we plan on having
> will be based on that. I hope to have more news in the upcoming weeks.
>
> Personally I couldn't care less about curly brackets, but we should decide
> on whitespaces/tabs and use stylecop or similar to enforce that, for
> readability sake
>
> --
>
> 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 4:17 PM, Simon Svensson <si...@devhost.se> wrote:
>
>> Outline!
>>
>> Regarding the extension methods mentioned at the end, I'm talking about
>> introducing such a class/helper into the core Lucene.Net assembly for use
>> of non-test assemblies. Those I've found so far (JavaCompatilibity/*.cs in
>> Lucene.Test.Framework) are for tests only. Your mails from April 20th
>> indicate that the purpose of such helper methods are for quick porting of
>> tests only.
>>
>> One example would be the java substring function. I've been bitten several
>> times (and never seem to learn) that the parameters are different between
>> java and .net.
>>
>> [Obsolete("Call String.Substring instead. Note that Java uses
>> start+end while .NET uses start+length")]
>> public static String substring(this String value, Int32 start,
>> Int32 end) {
>> return value.Substring(start, end - start + 1);
>> }
>>
>> On another line of thought, are there any code formatting rules or plugins
>> that helps? I believe Resharper/StyleCop supports storing code formatting
>> settings in a file that can be commited so we're producing similar looking
>> code. Or should we start a religious war about curly braces and
>> whitespaces? ;)
>>
>> // Simon
>>
>>
>>
>> On 01/05/14 14:23, Itamar Syn-Hershko wrote:
>>
>>> 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 <si...@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
>>>>
>>>>
>>>>
Re: Porting questions
Posted by Itamar Syn-Hershko <it...@code972.com>.
Yes, this is why we are working towards having a good R# plugin that will
let us do Java to C# porting easily, taking into account things like you
mention. This may already be supported by Paul's library by the way, and if
it isn't it can certainly be added to it. The R# plugin we plan on having
will be based on that. I hope to have more news in the upcoming weeks.
Personally I couldn't care less about curly brackets, but we should decide
on whitespaces/tabs and use stylecop or similar to enforce that, for
readability sake
--
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 4:17 PM, Simon Svensson <si...@devhost.se> wrote:
> Outline!
>
> Regarding the extension methods mentioned at the end, I'm talking about
> introducing such a class/helper into the core Lucene.Net assembly for use
> of non-test assemblies. Those I've found so far (JavaCompatilibity/*.cs in
> Lucene.Test.Framework) are for tests only. Your mails from April 20th
> indicate that the purpose of such helper methods are for quick porting of
> tests only.
>
> One example would be the java substring function. I've been bitten several
> times (and never seem to learn) that the parameters are different between
> java and .net.
>
> [Obsolete("Call String.Substring instead. Note that Java uses
> start+end while .NET uses start+length")]
> public static String substring(this String value, Int32 start,
> Int32 end) {
> return value.Substring(start, end - start + 1);
> }
>
> On another line of thought, are there any code formatting rules or plugins
> that helps? I believe Resharper/StyleCop supports storing code formatting
> settings in a file that can be commited so we're producing similar looking
> code. Or should we start a religious war about curly braces and
> whitespaces? ;)
>
> // Simon
>
>
>
> On 01/05/14 14:23, Itamar Syn-Hershko wrote:
>
>> 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 <si...@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
>>>
>>>
>>>
>
Re: Porting questions
Posted by Simon Svensson <si...@devhost.se>.
Outline!
Regarding the extension methods mentioned at the end, I'm talking about
introducing such a class/helper into the core Lucene.Net assembly for
use of non-test assemblies. Those I've found so far
(JavaCompatilibity/*.cs in Lucene.Test.Framework) are for tests only.
Your mails from April 20th indicate that the purpose of such helper
methods are for quick porting of tests only.
One example would be the java substring function. I've been bitten
several times (and never seem to learn) that the parameters are
different between java and .net.
[Obsolete("Call String.Substring instead. Note that Java uses
start+end while .NET uses start+length")]
public static String substring(this String value, Int32 start,
Int32 end) {
return value.Substring(start, end - start + 1);
}
On another line of thought, are there any code formatting rules or
plugins that helps? I believe Resharper/StyleCop supports storing code
formatting settings in a file that can be commited so we're producing
similar looking code. Or should we start a religious war about curly
braces and whitespaces? ;)
// Simon
On 01/05/14 14:23, Itamar Syn-Hershko wrote:
> 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 <si...@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
>>
>>
Re: Porting questions
Posted by Itamar Syn-Hershko <it...@code972.com>.
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 <si...@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
>
>