Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAA0W1bShBB3owk_ThPeRnxef-HNRg-aCTJP07vYNpO67Wg5H7A@mail.gmail.com>
References: 
 <CAA0W1bShBB3owk_ThPeRnxef-HNRg-aCTJP07vYNpO67Wg5H7A@mail.gmail.com>
Date: Mon, 16 Mar 2015 11:51:25 -0700
Message-ID: 
 <CA+qbEUNk6giX-q8UQh8LkN6X5RGYG8KFVyHhwZRZin5p3wzGKg@mail.gmail.com>
Subject: Re: about CHANGES.txt
From: "Colin P. McCabe" <cmccabe@apache.org>
To: Hadoop Common <common-dev@hadoop.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+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 sol=
ve
> 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 doe=
s
> 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. Sin=
ce
> 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> wrot=
e:
>
>>
>> I think the general consensus is don=E2=80=99t include the changes.txt f=
ile in
>> your commit. It won=E2=80=99t be correct for both branches if such a com=
mit is
>> destined for both. (No, the two branches aren=E2=80=99t the same.)
>>
>> No, git log isn=E2=80=99t more accurate.  The problems are:
>>
>> a) cherry picks
>> b) branch mergers
>> c) =E2=80=9Cwhoops i missed something in that previous commit=E2=80=9D
>> 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 buil=
d
>> release notes from JIRA, BTW.  (Not that anyone appears to read them giv=
en
>> the low quality of our notes=E2=80=A6)  Anyway, here=E2=80=99s what I=E2=
=80=99ve 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.c=
om
>> >
>> > wrote:
>> >
>> >> JIRA already provides a report:
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=3D1232717=
9&styleName=3DHtml&projectId=3D12310240
>> >>
>> >>
>> >> 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 th=
e
>> >> 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 for=
get
>> >>>> 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
>> >>>
>> >>
>>
>>