hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yongjun Zhang <yzh...@cloudera.com>
Subject Re: about CHANGES.txt
Date Sun, 15 Mar 2015 03:36:04 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message