hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: about CHANGES.txt
Date Tue, 17 Mar 2015 18:21:35 GMT

	Nope.  I’m not particularly in the mood to write a book about a topic that I’ve beat
to death in private conversations over the past 6 months other than highlighting that any
solution needs to be able to work against scenarios like we had 3 years ago with four active
release branches + trunk.

On Mar 17, 2015, at 10:56 AM, Yongjun Zhang <yzhang@cloudera.com> wrote:

> Thanks Ravi and Colin for the feedback.
> 
> Hi Allen,
> 
> You pointed out that "git log" has problem when dealing with branch that
> has merges, would you please elaborate the problem?
> 
> Thanks.
> 
> --Yongjun
> 
> On Mon, Mar 16, 2015 at 7:08 PM, Colin McCabe <cmccabe@alumni.cmu.edu>
> wrote:
> 
>> Branch merges made it hard to access change history on subversion
>> sometimes.
>> 
>> You can read the tale of woe here:
>> 
>> http://programmers.stackexchange.com/questions/206016/maintaining-svn-history-for-a-file-when-merge-is-done-from-the-dev-branch-to-tru
>> 
>> Excerpt:
>> "....prior to Subversion 1.8. The files in the branch and the files in
>> trunk are copies and Subversion keeps track with svn log only for
>> specific files, not across branches."
>> 
>> I think that's how the custom of CHANGES.txt started, and it was
>> cargo-culted forward into the git era despite not serving much purpose
>> any more these days (in my opinion.)
>> 
>> best,
>> Colin
>> 
>> On Mon, Mar 16, 2015 at 4:49 PM, Ravi Prakash <ravihoo@ymail.com> wrote:
>>> +1 for automating the information contained in CHANGES.txt. There are
>> some changes which go in without JIRAs sometimes (CVEs eg.) . I like git
>> log because its the absolute source of truth (cryptographically secure,
>> audited, distributed, yadadada). We could always use git hooks to force a
>> commit message format.
>>> a) cherry-picks have the same message (by default) as the original)b)
>> I'm not sure why branch-mergers would be a problem?c) "Whoops I missed
>> something in the previous commit" wouldn't happen if our hooks were
>> smartishd) "no identification of what type of commit it was without hooking
>> into JIRA anyway." This would be in the format of the commit message
>>> 
>>> Either way I think would be an improvement.
>>> Thanks for your ideas folks
>>> 
>>> 
>>> 
>>>     On Monday, March 16, 2015 11:51 AM, Colin P. McCabe <
>> cmccabe@apache.org> wrote:
>>> 
>>> 
>>> +1 for generating CHANGES.txt from JIRA and/or git as part of making a
>>> release.  Or just dropping it altogether.  Keeping it under version
>>> control creates lot of false conflicts whenever submitting a patch and
>>> generally makes committing minor changes unpleasant.
>>> 
>>> Colin
>>> 
>>> On Sat, Mar 14, 2015 at 8:36 PM, Yongjun Zhang <yzhang@cloudera.com>
>> wrote:
>>>> Hi Allen,
>>>> 
>>>> Thanks a lot for your input!
>>>> 
>>>> Looks like problem a, c, d you listed is not too bad, assuming we can
>> solve
>>>> d by pulling this info from jira as Sean pointed out.
>>>> 
>>>> Problem b (branch mergers) seems to be a real one, and your approach of
>>>> using JIRA system to build changes.txt is a reasonably good way. This
>> does
>>>> count on that we update jira accurately. Since this update is a manual
>>>> process, it's possible to have inconsistency, but may be not too bad.
>> Since
>>>> any mistake found here can be remedied by fixing the jira side and
>>>> refreshing the result.
>>>> 
>>>> I wonder if we as a community should switch to using your way, and save
>>>> committer's effort of taking care of CHANGES.txt (quite some save IMO).
>>>> Hope more people can share their thoughts.
>>>> 
>>>> Thanks.
>>>> 
>>>> --Yongjun
>>>> 
>>>> On Fri, Mar 13, 2015 at 4:45 PM, Allen Wittenauer <aw@altiscale.com>
>> wrote:
>>>> 
>>>>> 
>>>>> I think the general consensus is don’t include the changes.txt file
in
>>>>> your commit. It won’t be correct for both branches if such a commit
is
>>>>> destined for both. (No, the two branches aren’t the same.)
>>>>> 
>>>>> No, git log isn’t more accurate.  The problems are:
>>>>> 
>>>>> a) cherry picks
>>>>> b) branch mergers
>>>>> c) “whoops i missed something in that previous commit”
>>>>> d) no identification of what type of commit it was without hooking into
>>>>> JIRA anyway.
>>>>> 
>>>>> This is why I prefer building the change log from JIRA.  We already
>> build
>>>>> release notes from JIRA, BTW.  (Not that anyone appears to read them
>> given
>>>>> the low quality of our notes…)  Anyway, here’s what I’ve been
>>>>> building/using as changes.txt and release notes:
>>>>> 
>>>>> https://github.com/aw-altiscale/hadoop-release-metadata
>>>>> 
>>>>> I try to update these every day. :)
>>>>> 
>>>>> On Mar 13, 2015, at 4:07 PM, Yongjun Zhang <yzhang@cloudera.com>
>> wrote:
>>>>> 
>>>>>> Thanks Esteban, I assume this report gets info purely from the jira
>>>>>> database, but not "git log" of a branch, right?
>>>>>> 
>>>>>> I hope we get the info from "git log" of a release branch because
>> that'd
>>>>> be
>>>>>> more accurate.
>>>>>> 
>>>>>> --Yongjun
>>>>>> 
>>>>>> On Fri, Mar 13, 2015 at 3:11 PM, Esteban Gutierrez <
>> esteban@cloudera.com
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> JIRA already provides a report:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12327179&styleName=Html&projectId=12310240
>>>>>>> 
>>>>>>> 
>>>>>>> cheers,
>>>>>>> esteban.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Cloudera, Inc.
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Mar 13, 2015 at 3:01 PM, Sean Busbey <busbey@cloudera.com>
>>>>> wrote:
>>>>>>> 
>>>>>>>> So long as you include the issue number, you can automate
pulling
>> the
>>>>>>> type
>>>>>>>> from jira directly instead of putting it in the message.
>>>>>>>> 
>>>>>>>> On Fri, Mar 13, 2015 at 4:49 PM, Yongjun Zhang <
>> yzhang@cloudera.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> I found that changing CHANGES.txt when committing a jira
is error
>>>>> prone
>>>>>>>>> because of the different sections in the file, and sometimes
we
>> forget
>>>>>>>>> about changing this file.
>>>>>>>>> 
>>>>>>>>> After all, git log would indicate the history of a branch.
I
>> wonder if
>>>>>>> we
>>>>>>>>> could switch to a new method:
>>>>>>>>> 
>>>>>>>>> 1. When committing, ensure the message include the type
of the
>> jira,
>>>>>>> "New
>>>>>>>>> Feature", "Bug Fixes", "Improvement" etc.
>>>>>>>>> 
>>>>>>>>> 2. No longer need to make changes to CHANGES.txt for
each commit
>>>>>>>>> 
>>>>>>>>> 3. Before releasing a branch, create the CHANGES.txt
by using "git
>>>>> log"
>>>>>>>>> command for the given branch..
>>>>>>>>> 
>>>>>>>>> Thanks.
>>>>>>>>> 
>>>>>>>>> --Yongjun
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Sean
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>> 


Mime
View raw message