hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin P. McCabe" <cmcc...@apache.org>
Subject Re: about CHANGES.txt
Date Mon, 16 Mar 2015 18:51:25 GMT
+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