lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Svensson <si...@devhost.se>
Subject Re: Outstanding issues for 3.0.3
Date Sun, 08 Jul 2012 19:28:47 GMT
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
>>
>>
>>
>> CLS Compliance 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. 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
>>>
>>> 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
>>>>>
>>>>> 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
View raw message