lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: Outstanding issues for 3.0.3
Date Mon, 09 Jul 2012 17:21:42 GMT
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 <sisve@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 <geobmx540@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: thoward37@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-dev@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 <geobmx540@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: mherndon@wickedsoftware.net
>>>>>> To: lucene-net-dev@lucene.apache.**org<lucene-net-dev@lucene.apache.org>
>>>>>>
>>>>>> On Sat, Jun 23, 2012 at 1:38 AM, Prescott Nasser <
>>>>>>
>>>>> geobmx540@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
>>>>>>>
>>>>>>
>
>

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