Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of rcmuir@gmail.com designates
 209.85.161.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=pQd6CHbgYmP03lJA0AF85LMZTe63uZw+MC/5DDNvxCmATph665rE1UkhWE93pB+EBx
         HvpFYrWGtfVkNG0n8J+JikHC/IXam1z6fwIaJRDsjltyc6kyIMK4D1y3DBW9Y45iAe1q
         +0Gyu3TQIvzo+WO6owGun/GYB8/P7YYFV/l3k=
MIME-Version: 1.0
In-Reply-To: <939E3562-CE7D-415C-90F2-82749A73BA06@jpl.nasa.gov>
References: <000d01cb9163$22ac2d10$68048730$@thetaphi.de>
 <AANLkTimw-HECMVU2imASbmouE+n8VikH_Z8KXPMd6pFy@mail.gmail.com>
 <D199B09F-7CF0-4E4A-8DF7-702EF4F80F41@apache.org>
 <4CFB2B3F.4050308@gmail.com>
 <D0725770-DB77-461E-91F7-FEF0661AD793@jpl.nasa.gov>
 <AANLkTimajfRoXD9KH6=beAYd3+kxbVCMs4rEOhOpd10u@mail.gmail.com>
 <7669DC24-B379-472B-B551-CCA9B441D502@jpl.nasa.gov>
 <AANLkTim0fYkEWQX3BbMsR39OaRfpurdcwtxwZ1GFW=Aw@mail.gmail.com>
 <25C239A9-7320-4735-AE19-CE3CD5D70510@jpl.nasa.gov>
 <AANLkTi=3EvgpiGVFAOLEmckyWDpr1709bGY4=WKtYooy@mail.gmail.com>
 <939E3562-CE7D-415C-90F2-82749A73BA06@jpl.nasa.gov>
From: Robert Muir <rcmuir@gmail.com>
Date: Mon, 6 Dec 2010 11:31:37 -0500
Message-ID: <AANLkTi=M8E33xeXetKAV4bM_7tcs11LNdYBmY479_uat@mail.gmail.com>
Subject: Re: Changes Mess
To: dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 6, 2010 at 11:20 AM, Mattmann, Chris A (388J)
<chris.a.mattmann@jpl.nasa.gov> wrote:
>
> Yeah in the end all I can say is that you basically get out of JIRA what =
you put into it. What you call extra work is just something that I would do=
 anyways working on some of my projects. I'm not saying it's *not difficult=
* and super easy, but we've just decided in those cases to invest time into=
 the issue management system so that we can get the reports we want out of =
it.
>
> I've seen this work both ways: in the early days of Nutch there were inte=
nse debates on simply moving everything to JIRA versus maintaining a discon=
nected CHANGES.txt file. I've heard all the arguments (many times over) on =
both sides including tidbits like "oh I don't want to go to a separate URL =
as a consumer of software just to see what changed in it" to "what's so har=
d about doing a curl or wget on an Internet-connected system which most of =
our software assumes nowadays"?, those types of things.
>
> When the dust cleared, I think I like the approach we use in Tika (and th=
at I use in a number of projects at JPL) which is just to maintain the info=
rmation in JIRA. It's worked for us since it's a single source to curate th=
at type of information; it produces very useable reports (not perfect, but =
useable) that are good enough for us in terms of trading between the differ=
ent properties we want to maximize (user contribution acknowledgement, chan=
ge history, etc.)
>

I agree with what you said, and as I mentioned before I'm not opposed
to the idea at all.

But if we are going to rely on JIRA more to produce this
documentation, we need to make some major changes to how we use it, to
avoid some of the problems I mentioned...

The scariest part to me about this approach is that we unfortunately
have very long release cycles. So i'm worried about this documentation
being generated and fixed "at release time" versus incrementally where
its fresh in our mind... thats a lot of editing and filtering to do.

Obviously I feel this would be mitigated and other things much better
if we released more often but thats a harder problem, this is just the
situation as it is now.

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