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 <[email protected]> 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 > >
