RE: issues.apache.org compromised: please update your passwords

> > > Hi Grant, > > > > > > It is that user, who is assigned to the very early JIRA issues, > e.g.: > > > https://issues.apache.org/jira/browse/LUCENE-1 > > > > > > I changed the password of this user in response to that email (for > security), but I think we should simply let infra remove it. T

Re: Proposal about Version API "relaxation"

On Wed, Apr 14, 2010 at 12:06 AM, Marvin Humphrey wrote: > New class names would work, too. > > I only mention that for the sake of completeness, though -- it's not a > suggestion. > Right, to me this is just as bad. In my eyes, the Version thing really shows the problem with the analysis stuff:

Re: Proposal about Version API "relaxation"

On Tue, Apr 13, 2010 at 02:46:56PM -0400, Robert Muir wrote: > Unlike other components in Lucene, Analyzers get hit the worst because any > change is basically a break, and there's really not any other option besides > Version to implement any backwards compatibility for them. New class names wou

Re: issues.apache.org compromised: please update your passwords

On Wed, Apr 14, 2010 at 01:08:41AM +0100, sebb wrote: > On 14/04/2010, Uwe Schindler wrote: > > Hi Grant, > > > > It is that user, who is assigned to the very early JIRA issues, e.g.: > > https://issues.apache.org/jira/browse/LUCENE-1 > > > > I changed the password of this user in response to t

Re: issues.apache.org compromised: please update your passwords

I wonder if that user was setup a while ago as a way of getting update messages to the mailing list (maybe in the very early days of JIRA before notification schemes). I'd suggest we disable the account. -Grant On Apr 13, 2010, at 8:08 PM, sebb wrote: > On 14/04/2010, Uwe Schindler wrote: >>

Re: FindBugs Community Review of Lucene

Hi Nat: Great analysis! Some of them DO seem to be bugs! Maybe findbugs can be enabled as part of the build? -John On Tue, Apr 13, 2010 at 11:01 AM, Nat Ayewah wrote: > Hello, > > I am a PhD student working with the FindBugs project, at the University of > Maryland. FindBugs

RE: issues.apache.org compromised: please update your passwords

Hi Grant, It is that user, who is assigned to the very early JIRA issues, e.g.: https://issues.apache.org/jira/browse/LUCENE-1 I changed the password of this user in response to that email (for security), but I think we should simply let infra remove it. The problem is, almost anybody can instr

Re: issues.apache.org compromised: please update your passwords

FYI, this is for real. Some have asked me if it is made up. I don't know who owns that user, so we should ask on infra, I suspect. Also, this applies to all user accounts too on JIRA. On Apr 13, 2010, at 12:25 PM, r...@apache.org wrote: > Dear Lucene Developers, > > You are receiving this

[jira] Commented: (LUCENE-2208) Token div exceeds length of provided text sized 4114

[ https://issues.apache.org/jira/browse/LUCENE-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856670#action_12856670 ] Luke Forehand commented on LUCENE-2208: --- Sorry for what seems like cross posting, bu

Re: [jira] Account password

Oops, that'll teach me to just skim things, won't it? Erick On Tue, Apr 13, 2010 at 6:14 PM, Andi Vajda wrote: > > On Tue, 13 Apr 2010, Erick Erickson wrote: > > A, good. That means the very long e-mail that came to my regular >> account >> about someone hacking the JIRA server is bogus to

Re: [jira] Account password

On Tue, 13 Apr 2010, Erick Erickson wrote: A, good. That means the very long e-mail that came to my regular account about someone hacking the JIRA server is bogus too I assume.. Err, no, it's real. You should change your password. Andi.. Erick On Tue, Apr 13, 2010 at 5:58 PM, Uwe

Re: [jira] Account password

On Tue, Apr 13, 2010 at 6:06 PM, Erick Erickson wrote: > A, good. That means the very long e-mail that came to my regular account > about someone hacking the JIRA server is bogus too I assume.. > Erick Not sure about the mail, but that part is true... https://blogs.apache.org/infra/entry

Re: [jira] Account password

It wasn't On Wed, Apr 14, 2010 at 02:06, Erick Erickson wrote: > A, good. That means the very long e-mail that came to my regular account > about someone hacking the JIRA server is bogus too I assume.. > Erick > > On Tue, Apr 13, 2010 at 5:58 PM, Uwe Schindler wrote: >> >> LOL! >> >> Thi

Re: [jira] Account password

A, good. That means the very long e-mail that came to my regular account about someone hacking the JIRA server is bogus too I assume.. Erick On Tue, Apr 13, 2010 at 5:58 PM, Uwe Schindler wrote: > LOL! > > This user is assigned to very old bugzilla issues :-) > > - > Uwe Schindler >

RE: [jira] Account password

I changed the password, so its no longer public. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Tuesday, April 13, 2010 11:59 PM > To: java-dev@lucene.apa

RE: [jira] Account password

LOL! This user is assigned to very old bugzilla issues :-) - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: j...@apache.org [mailto:j...@apache.org] > Sent: Tuesday, April 13, 2010 10:54 PM > To: java-dev

Re: [jira] Account password

Priceless On Wed, Apr 14, 2010 at 00:53, wrote: > >  You (or someone else) has reset your password. > > - > > Your password has been changed to: MCwqNr > > You can change your password here: > >   https://issues.apache.org/jira/

Re: Proposal about Version API "relaxation"

On Tue, Apr 13, 2010 at 12:41 PM, Uwe Schindler wrote: > Hi Shai, > > > > one of the problem I have is: That is a static default! We want to get rid > of them (and did it mostly, only some relicts remain), so there are no plans > to reimplement such a thing again. The badest one is > BooleanQuery.

Re: Proposal about Version API "relaxation"

I agree with Uwe. We shouldn't use non-final public statics. Thinking out loud: Could IndexWriter/IndexReader propagate the Version to the downstream classes (e.g. IndexWriter to Analyzers, IndexReader to queries) if not previously explicitly set? E.g. an IndexWriter calls setVersion on an

[jira] Account password

You (or someone else) has reset your password. - Your password has been changed to: MCwqNr You can change your password here: https://issues.apache.org/jira/secure/ViewProfile.jspa Here are the details of your account: -

Re: Proposal about Version API "relaxation"

On Apr 13, 2010, at 2:09 PM, Shai Erera wrote: > > And I guess that what bothers me the most is that it feels to me like we're > trying to protect people from stuff we haven't yet received complaints on (at > least none that I'm aware of), I think we have, they just aren't explicitly stated b/

[jira] Resolved: (LUCENE-2366) LLRect.createBox returned box does not contains all points in (center,distance) disc

[ https://issues.apache.org/jira/browse/LUCENE-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved LUCENE-2366. - Resolution: Fixed Committed revision 933754. > LLRect.createBox returned box does not c

[jira] Commented: (LUCENE-2359) CartesianPolyFilterBuilder doesn't handle edge case around the 180 meridian

[ https://issues.apache.org/jira/browse/LUCENE-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856565#action_12856565 ] Grant Ingersoll commented on LUCENE-2359: - Committed Nicolas' updates to trunk >

[jira] Resolved: (LUCENE-2367) CartesianPolyFilterBuilder has problems around the poles

[ https://issues.apache.org/jira/browse/LUCENE-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved LUCENE-2367. - Resolution: Fixed Committed Nicolas' patch to trunk > CartesianPolyFilterBuilder has pr

[jira] Assigned: (LUCENE-2367) CartesianPolyFilterBuilder has problems around the poles

[ https://issues.apache.org/jira/browse/LUCENE-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned LUCENE-2367: --- Assignee: Grant Ingersoll > CartesianPolyFilterBuilder has problems around the poles

Re: Proposal about Version API "relaxation"

> Because the version mechanism is not a single value for the entire library but rather feature by feature. I don't see how a global setter can help. That's only true if we believe people use different Version values in different places of their code ... and note that they will still be able to. I

issues.apache.org compromised: please update your passwords

Dear Lucene Developers, You are receiving this email because you have a login, 'java-dev@lucene.apache.org', on the Apache JIRA installation, https://issues.apache.org/jira/ On April 6 the issues.apache.org server was hacked. The attackers were able to install a trojan JIRA login screen and la

Re: Proposal about Version API "relaxation"

On Tue, Apr 13, 2010 at 2:39 PM, Marvin Humphrey wrote: > > > I wonder if it's possible to solve this problem for Analyzers by decoupling > their distribution from the Lucene core and versioning them separately. > I.e. > remove MatchVersion and increment individual Analyzer version numbers > inste

Re: Proposal about Version API "relaxation"

I like the concept of version, but I'm concerned about it too. The current Version mechanism allows one to use more than one Version in their code. Imagine that we are at 3.2 and one was unable to upgrade to a most version for a particular feature. Let's also suppose that at 3.2 a new feature

Re: Proposal about Version API "relaxation"

On Tue, Apr 13, 2010 at 11:17:56AM -0700, Andi Vajda wrote: > Using global statics is flawed. +1. I wonder if it's possible to solve this problem for Analyzers by decoupling their distribution from the Lucene core and versioning them separately. I.e. remove MatchVersion and increment individual

Re: Proposal about Version API "relaxation"

On Tue, Apr 13, 2010 at 2:09 PM, Shai Erera wrote: > Because the fact to the matter is - we invented Version to allow for > changes w/o breaking back-compat, while the backwards section in CHANGES > seems to grow from release to release (I know - I'm partly to blame for it > :)), and another fac

Re: Proposal about Version API "relaxation"

On Apr 13, 2010, at 11:09, Shai Erera wrote: > That is a static default! Yes Uwe ... I'm aware of that :) But that's not a static default for Lucene ... only for the application, if it chooses to use it ... So you have two apps on the same vm and both choose to use this global and pick

[jira] Commented: (LUCENE-2316) Define clear semantics for Directory.fileLength

[ https://issues.apache.org/jira/browse/LUCENE-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856531#action_12856531 ] Shai Erera commented on LUCENE-2316: That's a fairly trivial patch, therefore I plan t

Re: Proposal about Version API "relaxation"

> That is a static default! Yes Uwe ... I'm aware of that :) But that's not a static default for Lucene ... only for the application, if it chooses to use it ... > so there are no plans to reimplement such a thing again Well ... that's not exactly what I'm proposing here. I'm not for re-implemen

[jira] Commented: (LUCENE-2208) Token div exceeds length of provided text sized 4114

[ https://issues.apache.org/jira/browse/LUCENE-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856520#action_12856520 ] Luke Forehand commented on LUCENE-2208: --- I just opened a bug for what appears to be

FindBugs Community Review of Lucene

Hello, I am a PhD student working with the FindBugs project, at the University of Maryland. FindBugs is a popular open source static analysis tool that can analyze Java software and identify bugs. We recently analyzed *Lucene*, and identified about 22 warnin

[jira] Commented: (LUCENE-2355) Refactor Directory/Multi/SegmentReader creation/reopening/cloning/closing

[ https://issues.apache.org/jira/browse/LUCENE-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856509#action_12856509 ] Earwin Burrfoot commented on LUCENE-2355: - - Norms do both backward and forward sh

RE: Proposal about Version API "relaxation"

Hi Shai, one of the problem I have is: That is a static default! We want to get rid of them (and did it mostly, only some relicts remain), so there are no plans to reimplement such a thing again. The badest one is BooleanQuery.maxClauseCount. The same applies to all types of sysprops. As Luc

Re: Proposal about Version API "relaxation"

Well the no-arg ctor will be using Version.getDefault() which will throw an exception if not set, and delegate the call to the Version-aware ctor. On Tuesday, April 13, 2010, Robert Muir wrote: > On Tue, Apr 13, 2010 at 11:27 AM, Shai Erera wrote: > > > I was thinking that we can add on Version

[jira] Commented: (LUCENE-2371) Update fileformats spec to match how flex's standard codec writes terms

[ https://issues.apache.org/jira/browse/LUCENE-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856479#action_12856479 ] Michael McCandless commented on LUCENE-2371: Reminder to future self: make sur

Re: Proposal about Version API "relaxation"

On Tue, Apr 13, 2010 at 11:27 AM, Shai Erera wrote: > I was thinking that we can add on Version a DEFAULT version, which the > caller can set. So Version.setDefault and Version.getDefault will be added, > as static members (more on the static-ness of it later). We then change the > API which requ

[jira] Resolved: (LUCENE-2111) Wrapup flexible indexing

[ https://issues.apache.org/jira/browse/LUCENE-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-2111. Resolution: Fixed > Wrapup flexible indexing > > >

[jira] Updated: (LUCENE-2316) Define clear semantics for Directory.fileLength

[ https://issues.apache.org/jira/browse/LUCENE-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-2316: --- Attachment: LUCENE-2316.patch Patch clarifies the contract, fixes the directories to adhere to it an

Re: Proposal about Version API "relaxation"

On Tue, Apr 13, 2010 at 11:27 AM, Shai Erera wrote: > Hi > > I'd like to propose a relaxation on the Version API. Uwe, please read the > entire email before you reply :). > > I was thinking, following a question on the user list, that the > Version-based API may not be very intuitive to users, esp

Re: Proposal about Version API "relaxation"

I wholeheartedly support this anti-version riot :) On Tue, Apr 13, 2010 at 19:27, Shai Erera wrote: > Hi > > I'd like to propose a relaxation on the Version API. Uwe, please read the > entire email before you reply :). > > I was thinking, following a question on the user list, that the > Version-

Proposal about Version API "relaxation"

Hi I'd like to propose a relaxation on the Version API. Uwe, please read the entire email before you reply :). I was thinking, following a question on the user list, that the Version-based API may not be very intuitive to users, especially those who don't care about versioning, as well as very in

[jira] Resolved: (LUCENE-2386) IndexWriter commits unnecessarily on fresh Directory

[ https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-2386. Resolution: Fixed Committed revision 933613. (take #2) > IndexWriter commits unnecessarily on fre

[jira] Resolved: (LUCENE-1709) Parallelize Tests

[ https://issues.apache.org/jira/browse/LUCENE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-1709. - Resolution: Fixed I've propagated Shai's improvements to Solr. Additionally, I added the ant lib

[jira] Commented: (LUCENE-2386) IndexWriter commits unnecessarily on fresh Directory

[ https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856357#action_12856357 ] Michael McCandless commented on LUCENE-2386: Patch looks good Shai! > IndexWr