Confirming that is what the intent was all about, and wasn’t meant to single anyone out. Everyone has made errors in the git log. The YARN-2429 one was a great, timely example given the recent discussion here and in HADOOP-11731 to showcase that the git log is not a single, trustworthy source.
On Apr 8, 2015, at 12:33 AM, Karthik Kambatla <ka...@cloudera.com> wrote: > Tsuyoshi - don't worry about it. Happens to all of us, we all try but the > manual steps are understandably error-prone. I believe Allen's intent was > more to say why we shouldn't use git log for release notes than > highlighting these commits :) > > On Tue, Apr 7, 2015 at 11:41 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote: > >> 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... >>>> >> > > > > -- > Karthik Kambatla > Software Engineer, Cloudera Inc. > -------------------------------------------- > http://five.sentenc.es
