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 <a...@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 <yzh...@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 <este...@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 <bus...@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 <yzh...@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 > >>> > >> > >
