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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]> 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 <
>> [email protected]> 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 <[email protected]>
>> 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 <[email protected]>
>> 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 <[email protected]>
>> 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 <
>> [email protected]
>>>>>>
>>>>>> 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 <[email protected]>
>>>>> 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 <
>> [email protected]>
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
