Oops, sorry for YARN-2666. I forgot to include JIRA number in git repository. I'll see to it more and more based on the result of this discussion.
- Tsuyoshi On Wed, Apr 8, 2015 at 10:13 AM, Colin P. McCabe <cmcc...@apache.org> wrote: > The solution to this problem (if it is really a problem) is to keep > around a side file with some errata. I have such a side file that I > use with my script which compares two branches via git log. There's > always commits where the wrong message got applied, or the jira number > was missing, or etc. You can just have your script ignore those > commits. Real-world data is always a little dirty. > > Anyway, as Allen mentioned earlier, the git log is more likely to be > correct than CHANGES.txt, since git never forgets to handle merges and > cherry-picks, and humans often do. I think it's pretty rare to > remember to do one but forget the other. It is true that CHANGES.txt > can be mutated, whereas commit hashes cannot. But if the CHANGES.txt > change update was a separate commit, most people doing backports and > cherry-picks will miss it, so... I wouldn't count on that really > helping things much. > > I certainly have no objection to generating CHANGES.txt and release > notes off JIRA, which avoids some of these problems (jiras can be > edited, after all). But JIRA has its own set of problems... it's not > always available and it's centralized. If the JIRA REST APIs change, > or the data center loses its backups, or you don't have a network > connection, you can't examine JIRA. But you can always examine git > log. > > Colin > > On Tue, Apr 7, 2015 at 3:51 PM, Allen Wittenauer <a...@altiscale.com> wrote: >> >> For those wondering, YARN-2429 is the wrong JIRA for that commit. Simple >> typo, but deadly if one is using to use the git log to determine what’s >> actually committed... >>
