I made some progress on 480 - checked into the 3.5 branch, there is more work to be done we could potentially move it to 3.0.3, but I put it into 3.5 because I felt that we were closer to having this released, and adding those changes would add a fair amount of change so close to the release. I can add it back to the schedule, though I'm mostly just doing administrative work for the next two weeks though - I have a few things I have to take care ofÂ
---------------------------------------- > Date: Mon, 9 Jul 2012 10:21:42 -0700 > Subject: Re: Outstanding issues for 3.0.3 > From: currens.ch...@gmail.com > To: lucene-net-...@lucene.apache.org > > The tests should all be fine now. We had a contributer, Luc Vanlerberghe, > who did a LOT of work for us, getting these last few difficult bugs out of > the way. He's responsible for half or more of the failing tests from > LUCENENET-484 getting fixed, as well as LUCENE-493, with the culture > sensitivity. Also, I think we should no longer get any culture issues, > since the tests that are marked as culture sensitive are now all run in all > installed cultures on the machine. > > I think CLS compliance is still important and should be handled. What > about LUCENENET-480? I know that Prescott had done some work on this and I > also know this was requested by several in the community. I would love to > see that make it into 3.0.3, and would be able to pick up where anyone had > left off or take part of it, if they don't have time to work on it. In > regards to LUCENENET-446, I agree that it is pretty much complete. I think > I've looked several times at it to confirm most/all methods have been > converted, so this week I'll do a final check and close it out. > > > Thanks, > Christopher > > On Sun, Jul 8, 2012 at 12:28 PM, Simon Svensson <si...@devhost.se> wrote: > > > The tests that failed when using culture=sv-se seems fixed. > > > > > > On 2012-07-08 20:44, Itamar Syn-Hershko wrote: > > > >> What's the status on the failing tests we had? > >> > >> On Sun, Jul 8, 2012 at 9:02 PM, Prescott Nasser <geobmx...@hotmail.com > >> >wrote: > >> > >> Three issues left that I see: > >>> > >>> > >>> > >>> Fixing the build output, I did some work, but I'm good on this, we can > >>> move the rest of work to 3.6 > >>> https://issues.apache.org/**jira/browse/LUCENENET-456<https://issues.apache.org/jira/browse/LUCENENET-456> > >>> > >>> > >>> > >>> CLS Compliance > >>> https://issues.apache.org/**jira/browse/LUCENENET-446<https://issues.apache.org/jira/browse/LUCENENET-446>. > >>> Are > >>> we ok with this as for now? There are still a good number of issues > >>> where, > >>> some we can't really fix (sbyte and volatile are out of scope imo). In a > >>> similiar vein, our own code uses some obsolete methods and we have a lot > >>> of > >>> variable declared but never used warnings (mentally, I treat most warning > >>> as an error) > >>> > >>> > >>> > >>> GetX/SetX - > >>> https://issues.apache.org/**jira/browse/LUCENENET-470<https://issues.apache.org/jira/browse/LUCENENET-470>. > >>> I think > >>> much of this has been removed, there are probably some pieces that left > >>> (and we have a difference of opinion in the group as well). > >>> > >>> > >>> > >>> > >>> > >>> I really think the only outstanding issue is the CLS compliance one, the > >>> rest can be moved to 3.6. With CLS compliance we have to ask if we've > >>> done > >>> enough for that so far, or if more is needed. I personally would like to > >>> see us make any API changes now, with the 3.0.3 release, but if we are > >>> comfortable with it, lets roll. > >>> > >>> > >>> > >>> What are your thoughts? > >>> > >>> > >>> > >>> ~P > >>> > >>> > >>> > >>> > >>> > >>> ------------------------------**---------- > >>> > >>>> From: thowar...@gmail.com > >>>> Date: Mon, 25 Jun 2012 10:34:37 -0700 > >>>> Subject: Re: Outstanding issues for 3.0.3 > >>>> To: lucene-net-dev@lucene.apache.**org<lucene-net-...@lucene.apache.org> > >>>> > >>>> Assuming we're talking about the packaging/filesystem structure in the > >>>> releases, the structure is a little of both (ours vs Apache's)... > >>>> Basically, I went through most of the Apache projects to see how they > >>>> packaged releases and developed a structure that was very similar but > >>>> encompassed everything we needed. So, it's informed by the organically > >>>> emergent structures that ASF uses. > >>>> > >>>> -T > >>>> > >>>> > >>>> On Mon, Jun 25, 2012 at 7:32 AM, Prescott Nasser <geobmx...@hotmail.com > >>>> > > >>>> > >>> wrote: > >>> > >>>> I have no idea why I thought we were using Nant. > >>>>> I think it's just "our release structure". I figured a little out this > >>>>> > >>>> weekend, splitting the XML and .dll files into separate directories. The > >>> documentation you have on the wiki was actually pretty helpful. > >>> > >>>> Whatever more you can add would be great > >>>>> > >>>>> ~P > >>>>> > >>>>> Date: Mon, 25 Jun 2012 10:04:21 -0400 > >>>>>> Subject: Re: Outstanding issues for 3.0.3 > >>>>>> From: mhern...@wickedsoftware.net > >>>>>> To: > >>>>>> lucene-net-dev@lucene.apache.**org<lucene-net-...@lucene.apache.org> > >>>>>> > >>>>>> On Sat, Jun 23, 2012 at 1:38 AM, Prescott Nasser < > >>>>>> > >>>>> geobmx...@hotmail.com>wrote: > >>> > >>>> > >>>>>>> -- Task 470, a non-serious one, is listed only because it's > >>>>>>>> > >>>>>>> mostly done > >>> > >>>> and > >>>>>>> > >>>>>>>> just need a few loose ends tied up. I'll hopefully have time to > >>>>>>>> > >>>>>>> take care > >>> > >>>> of that this weekend. > >>>>>>>> > >>>>>>> > >>>>>>> How many GetX/SetX are left? I did a quick search for 'public * > >>>>>>> > >>>>>> Get*()' > >>> > >>>> Most of them looked to be actual methods - perhaps a few to replace > >>>>>>> > >>>>>>> > >>>>>>> -- Task 446 (CLS Compliance), is important, but there's no way we > >>>>>>>> > >>>>>>> can get > >>> > >>>> this done quickly. The current state of this issue is that all of > >>>>>>>> > >>>>>>> the > >>> > >>>> names of public members are now compliant. There are a few things > >>>>>>>> > >>>>>>> that > >>> > >>>> aren't, the use of sbyte (particularly those related to the > >>>>>>>> > >>>>>>> FieldCache) > >>> > >>>> and > >>>>>>> > >>>>>>>> some conflicts with *protected or internal* fields (some with > >>>>>>>> > >>>>>>> public > >>> > >>>> members). Opinions on this one will be appreciated the most. My > >>>>>>>> > >>>>>>> opinion > >>> > >>>> is that we should draw a line on the amount of CLS compliance to > >>>>>>>> > >>>>>>> have in > >>> > >>>> this release, and push the rest into 3.5. > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I count roughly 53 CLS compliant issues. the sbyte stuff will run > >>>>>>> > >>>>>> into > >>> > >>>> trouble when you do bit shifting (I ran into this issue when trying > >>>>>>> > >>>>>> to do > >>> > >>>> this for 2.9.4. I'd like to see if we can't get rid of the easier > >>>>>>> > >>>>>> stuff > >>> > >>>> (internal/protected stuff). I would not try getting rid of sbyte or > >>>>>>> volatile for thile release. It's going to take some serious > >>>>>>> > >>>>>> consideration > >>> > >>>> to get rid of those > >>>>>>> > >>>>>>> > >>>>>>> -- Improvement 337 - Are we going to add this code (not present > >>>>>>>> > >>>>>>> in java) > >>> > >>>> to > >>>>>>> > >>>>>>>> the core library? > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I'd skip it and re-evaluate the community desire for this in 3.5. > >>>>>>> > >>>>>>> > >>>>>>> -- Improvement 456 - This is related to builds being output in > >>>>>>>> > >>>>>>> Apache's > >>> > >>>> release format. Do we want to do this for this release? > >>>>>>>> > >>>>>>>> > >>>>>>> I looked into this last weekend - I'm terrible with Nant, so I > >>>>>>> > >>>>>> didn't get > >>> > >>>> anywhere. It would be nice to have, but I don't think I'll figure > >>>>>>> > >>>>>> it out. > >>> > >>>> If Michael has some time to maybe make the adjustment, he knows > >>>>>>> > >>>>>> these > >>> > >>>> scripts best. If not I'm going to look into it, but I don't call > >>>>>>> > >>>>>> this a > >>> > >>>> show stopper - either we have it or we don't when the rest is done. > >>>>>>> > >>>>>>> With some Flo Rida and expresso shots, anything is possible. > >>>>>> > >>>>>> Did we switch to Nant? > >>>>>> > >>>>>> I saw the jira ticket for this. Is there an official apache release > >>>>>> structure or this just our* apache release structure that we are > >>>>>> > >>>>> using? > >>> > >>>> Can I take the latest release and use that to model the structure you > >>>>>> > >>>>> guys > >>> > >>>> want? > >>>>>> > >>>>>> @Prescott declarative xml build scripts are a pita in general. only > >>>>>> > >>>>> reason > >>> > >>>> we're using this over powershell or a scripting language is that mono > >>>>>> supports it and most .NET devs have it already installed. > >>>>>> > >>>>>> I'll spend some more time documenting it so that others can work on > >>>>>> > >>>>> it and > >>> > >>>> even refactor it. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ~P > >>>>>>> > >>>>>> > > > >
