Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of rcmuir@gmail.com designates
 209.85.214.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=LALKGVL9VmPh0nc/ikrdFDCoCHLwlo5db4tdHZbTLSqTWld1UCbysl365BztKOM/td
         TWYOl1jMQvwbagLWqUbEtfOPZ/tpe1cvuIT4zQm8HP1jdwkz0kUySeYCYH7TUDqKR4+9
         /uVieBOv6h9WgpJGOHrz0fL19Co1RjqIjzE7o=
MIME-Version: 1.0
In-Reply-To: <CA4A5C993E465A4292E14C850B2BBD26071BBB7D46@IMCMBX1.MITRE.ORG>
References: <CA4A5C993E465A4292E14C850B2BBD26071C5AA710@IMCMBX1.MITRE.ORG>
 <AANLkTimHYyxqhUJS9yf5TNp7pJSbRjDCyoBnnLFOh2pR@mail.gmail.com>
 <CA4A5C993E465A4292E14C850B2BBD26071BBB7D46@IMCMBX1.MITRE.ORG>
From: Robert Muir <rcmuir@gmail.com>
Date: Wed, 16 Feb 2011 05:40:33 -0500
Message-ID: <AANLkTi=cEU__JQ+hPVHGAVovkfWzSGFhXP0ZEKbM0REj@mail.gmail.com>
Subject: Re: Please mark distributed date faceting for 3.1
To: dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 16, 2011 at 12:06 AM, Smiley, David W. <dsmiley@mitre.org> wrot=
e:
> I may have added a test just now, but I and others have been using this [=
simple] code for some time now. =C2=A0It has "baked", it doesn't need more =
baking IMO.

I am sure people will say I am just being silly, but hudson does a
better job testing these things than people playing with the code. For
example, hudson randomizes external variables (locale X timezone)...
on the latest 1.6u23 there are 152 locales, and 609 timezones (only
424 "unique" according to raw offset + rules). With hudson selecting 1
of these ~ 65K possibilities 96 times a day, you can start to
calculate how long is a good "baking" for date-related functionality.

Someone can argue that because Solr insists on treating dates
internally, that this does not matter, but I have found and fixed
timezone and localization related bugs in Lucene and Solr before, so
that argument fails... not knowing the surrounding code, nothing makes
me feel better than a couple weeks of hudson grinding on the code.

Even then, sometimes a few weeks isnt enough.. for example if I
remember right, SOLR-1821 was daylight-savings related (note: the
issue was reported the very day daylight savings started in the United
States, but in other timezones it had not yet, and would fail for some
developers but not others).

> If this patch wasn't the biggest reason to not use distributed search (a =
key feature) then I wouldn't be here arguing my point. =C2=A0But I've appar=
ently lost this argument already so I give up;... assign if for 3.2 if that=
's the best you can do Rob. It's better than being unassigned which is what=
 it is now.
>

I don't think that would be the best, as its not my area of expertise.
If I see good patches being ignored because other devs are
time-constrained sometimes I will take the time to try to bring myself
up to speed to get them committed though, but I haven't yet given up
on this patch :)

Just so you know, Its nothing about your patch at all, I am just
against any new features of any sort being added to 3.1 at this point.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org