hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: Why I don't trust the git log: a fun git log challenge
Date Wed, 08 Apr 2015 15:35:52 GMT

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 <kasha@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 <ozawa@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 <cmccabe@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 <aw@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


Mime
View raw message