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 16:31:37 GMT
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 intense debates
on simply moving everything to JIRA versus maintaining a disconnected 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 hard 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 that I use in
a number of projects at JPL) which is just to maintain the information in JIRA. It's worked
for us since it's a single source to curate that type of information; it produces very useable
reports (not perfect, but useable) that are good enough for us in terms of trading between
the different properties we want to maximize (user contribution acknowledgement, change 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


Mime
View raw message