lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: Outstanding issues for 3.0.3
Date Sun, 08 Jul 2012 18:44:23 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message