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? -Todd -- Todd Lipcon Software Engineer, Cloudera
