Yah I agree with Jukka here, but don't worry too much Mike if you're verbose (or anyone else for that matter). The RM (aka "moi" ;) ) always can take a look at CHANGES.txt at the end of a release cycle (speaking of which, 1.0, ApacheCon, 1.0, ApacheCon ;) ) and distill the information to a manageable small amount.
Cheers, Chris On Oct 19, 2011, at 6:25 AM, Jukka Zitting wrote: > Hi, > > On Wed, Oct 19, 2011 at 1:06 PM, Nick Burch <[email protected]> wrote: >> Quick query - I notice that some people are updating CHANGES.txt when they >> close out issues. I had thought that part of the release process was going >> through the FIXED list in JIRA to build that up, so I hadn't been doing it. >> >> What's the view here, should we be doing it on most things, just major >> things, or holding off for the release manager to do it from a JIRA report? > > The most accurate and complete change history information should in > any case always be found in Jira and just referenced from CHANGES.txt, > so in my view there's no need to update CHANGES.txt for all or even > most changes. Most notably I'd rather not have us duplicate > information between Jira and CHANGES.txt. > > Instead the CHANGES.txt file is a good vehicle for pointing out > important changes or highlighting interesting new features that > otherwise might get lost in the noise. > > BR, > > Jukka Zitting ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
