lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject Re: Changes Mess
Date Tue, 07 Dec 2010 04:23:37 GMT
Jumping in late to this thread, though I've read most of it.

As a user and committer, I find the current CHANGES very convenient!
It's very easy for me to read what has changed in 3.0, and very easy
for me to put a CHANGES entry whenever I work on something that
warrants such entry.

And if an issue is back ported all the way 'till 1.4, then IMO it
should contain an entry in each CHANGES (of each release). Users who
download 2.9.4 need to be able to read what has changed since 2.9.3,
in a clear and concise way. Which as far as I'm concerned is the
current situation and I'm happy with it.

Back porting issues is usually a simple svn merge, and in more complex
cases, even if it's done manually, the CHANGES entry is the easiest to
copy over.

I don't think we should work hard to make JIRA produce the CHANGES for
us - in the end of the day, JIRA is our bug tracking system, and it
should remain like that. The CHANGES entry need to summarize the
change to the reader, and combined with the issue number it gives
enough info. If one wants, one can load the issue in JIRA and read the
full correspondence.

So I'm +1 for keeping things as they are, and paying attention to put
the entries in all applicable CHANGES.


On Monday, December 6, 2010, Mattmann, Chris A (388J)
<> wrote:
> Hey Robert,
> I feel ya. +1 to releasing more often! :)
> Cheers,
> Chris
> On Dec 6, 2010, at 8:31 AM, Robert Muir wrote:
>> On Mon, Dec 6, 2010 at 11:20 AM, Mattmann, Chris A (388J)
>> <> 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:
>> For additional commands, e-mail:
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email:
> WWW:
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message