lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Changes Mess
Date Tue, 07 Dec 2010 20:03:14 GMT
Both approaches have tradeoffs...

I love that the CHANGES today is carefully edited and as a result very
consumable to users.  The verbiage we put into a CHANGES entry is
necessarily different from the title we put into Jira since it's a
different audience.

But I don't like the confusion over which section we put an entry into
on all our branches, the work the RM must do to "dedup" (thanks Uwe!),
etc.  And we can't expect the RM to have to editorialize the changes
from "raw" Jira after the fact...

Could we do something hybrid?  Since we have no full control over
Jira, could we eg append a comment on the the Jira issue starting with
"CHANGES: ", if it needs a changes entry (many issues do not)?

Then on releasing we can pull from all issues fixed on that release
and coalesce the CHANGES?  This would fix the confusion of duping
CHANGES entries across releases, etc... it's just pushing a button.


On Mon, Dec 6, 2010 at 11:23 PM, Shai Erera <> wrote:
> 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.
> Shai
> 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:

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

View raw message