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. Mike On Mon, Dec 6, 2010 at 11:23 PM, Shai Erera <[email protected]> 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) > <[email protected]> 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) >>> <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Chris Mattmann, Ph.D. >> Senior Computer Scientist >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >> Office: 171-266B, Mailstop: 171-246 >> Email: [email protected] >> WWW: http://sunset.usc.edu/~mattmann/ >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Adjunct Assistant Professor, Computer Science Department >> University of Southern California, Los Angeles, CA 90089 USA >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
