ctubbsii commented on PR #20:
URL: https://github.com/apache/thrift-website/pull/20#issuecomment-4464653558

   @CJCombrink wrote:
   
   > there are always commits going in that are irrelevant to the end user so 
they don't belong on the CHANGELOG. The thrift project's approach of formal 
tickets in Jira has a distinct feature where it filters that out.
   
   The problem here is when projects, like Thrift, require that every commit 
correspond to a JIRA ticket, so you get a bunch of low value JIRA tickets just 
to correspond to a bunch of low value git commits. Having low-value JIRA 
tickets added to a CHANGELOG is no more helpful than viewing a bunch of low 
value git commit messages.
   
   > Now it takes hard work and effort to make sure the tickets correspond to 
the history, since as you say the history is the only source of truth, so there 
is room for improvement there, but personally I don't think just telling users 
to "go look at the history" is ideal.
   
   But that's not what I am advocating. I am advocating "look at the history" 
to replace the *automated* changelog that is currently being generated from 
low-value JIRA ticket descriptions. If the changelog is automated, it is no 
better than just looking at the git history.
   
   What I actually prefer instead of an automated CHANGELOG, is a curated set 
of release notes. See [Android release 
notes](https://developer.android.com/about/versions/17/release-notes) for an 
example. These are *far* superior to any automated release notes, and it's what 
Apache Accumulo [tries to 
do](https://accumulo.apache.org/release/accumulo-2.1.0/) as well.
   
   In summary:
   * For canonical source of truth, don't trust automated changelogs from JIRA; 
instead use git history, and
   * For meaningful understanding of what changed, don't generate automated 
changelogs full of low value output; use curated release notes instead.
   
   In either case, the automated JIRA Changelogs are superfluous.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to