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 18:20:06 GMT
If it's alright with you, I'll work on it a little bit in that branch, and
see what kind of progress I can make, since I have some time right now.

On Mon, Jul 9, 2012 at 11:06 AM, Prescott Nasser <geobmx540@hotmail.com>wrote:

>
> 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.chris@gmail.com
> > To: lucene-net-dev@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 <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