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
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: 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
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
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
