lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: Changes Mess
Date Mon, 06 Dec 2010 14:34:06 GMT
On Sun, Dec 5, 2010 at 10:35 PM, Mattmann, Chris A (388J)
<chris.a.mattmann@jpl.nasa.gov> wrote:
> Hi Robert,
>
> True, JIRA isn't a perfect solution for this matter, but works good enough usually since
many times (especially with prodding) those same users who report the bugs are those that
report the JIRA issues.
>

I agree it would be more ideal if we always tried to encourage users
to open JIRA issues.
But we cant "force" users to do this, you know and we should still fix
it + give them credit if they just don't reply at all.

I also agree with some of what Steven is saying: here's a concrete
example from 2.9.4 (just released):

CHANGES file:
LUCENE-2658: Exceptions while processing term vectors enabled for
multiple fields could lead to invalid ArrayIndexOutOfBoundsExceptions.

JIRA description:
LUCENE-2658: TestIndexWriterExceptions random failure: AIOOBE in
ByteBlockPool.allocSlice

So you see the story, i hit a random test failure and just opened an
issue describing that the test randomly failed.
Mike then went and fixed it and wrote up a CHANGES.txt entry thats
significantly better to the users.

In order for us to use JIRA here, we would have to do a lot of
JIRA-editing and re-organizing I think, and probably create a lot of
unnecessary issues.

For example, on some issues that I felt should only be "fixed" in
later releases, i wanted to still backport "documentation only" fixes
to 2.9.4/3.0.3.
Documentation only fixes aren't very risky and at least alert users to
the issue... but it would be bad if CHANGES.txt made them think it was
actually fixed!

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


Mime
View raw message