Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 48065 invoked from network); 6 Dec 2010 14:52:22 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Dec 2010 14:52:22 -0000 Received: (qmail 48763 invoked by uid 500); 6 Dec 2010 14:52:21 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 48687 invoked by uid 500); 6 Dec 2010 14:52:21 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 48680 invoked by uid 99); 6 Dec 2010 14:52:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Dec 2010 14:52:21 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [85.25.71.29] (HELO mail.troja.net) (85.25.71.29) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Dec 2010 14:52:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.troja.net (Postfix) with ESMTP id 080FED36006 for ; Mon, 6 Dec 2010 15:51:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.troja.net Received: from mail.troja.net ([127.0.0.1]) by localhost (megaira.troja.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oC4vCIYE-2j for ; Mon, 6 Dec 2010 15:51:46 +0100 (CET) Received: from [10.173.14.228] (unknown [89.204.137.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.troja.net (Postfix) with ESMTPSA id C1B9FD36005 for ; Mon, 6 Dec 2010 15:51:45 +0100 (CET) X-User-Agent: K-9 Mail for Android References: <000d01cb9163$22ac2d10$68048730$@thetaphi.de> <4CFB2B3F.4050308@gmail.com> <7669DC24-B379-472B-B551-CCA9B441D502@jpl.nasa.gov> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: Changes Mess From: Uwe Schindler Date: Mon, 06 Dec 2010 15:51:41 +0100 To: dev@lucene.apache.org Message-ID: If you have full control on your Jira installation, you could define a custom field named "changes entry and credits". This field could be used for a report. But we have no separate installation to have all control. Uwe "Robert Muir" schrieb: >On Sun, Dec 5, 2010 at 10:35 PM, Mattmann, Chris A (388J) > 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 -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org