On Mon, Nov 21, 2011 at 11:01 AM, Todd Lipcon <t...@cloudera.com> wrote: > I was thinking... our use of CHANGES.txt is a bit silly - we basically > maintain all of our changes in three places (a) JIRA fixVersion field, > (b) CHANGES.txt, and (c) the SVN changelog. It seems to me that we get > very little value out of CHANGES.txt -- the contents are way too large > (and terse) for any user to really follow, and it doesn't show us much > that JIRA wouldn't. > > Two possible proposals for discussion: > > Proposal 1) Completely remove CHANGES.txt. Part of the release job > would be to export the list of fixed JIRAs into an HTML file which we > can ship with the release. > > With this proposal I'd also consider adding a checkbox to JIRA for > "Include in changelist?" Anything with an explicit release note or the > "Include in changelist" checkbox would get published. > > Proposal 2) Leave CHANGES.txt, but make it more of a value judgment on > the part of the committer/patch author whether a patch deserves to go > in there. The main criteria would be "would a user care?" For example, > if it's a bug fix for something that regressed in SVN but was never > released, the user wouldn't care. If it's a bug fix from a previous > release, they would. If it's a minor build change or a fix to a unit > test, they wouldn't. etc etc (we could write up some guidelines on the > wiki) > > Any support for the above?
+1 to proposal #1. We can easily generate this from the change log and release notes.
