+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 <yzh...@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 <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 >> >>> >> >> >> >>
