It's probably worth mentioning that the HowToCommit wiki instructions actually say exactly what we need.
==snip== Always set the "Fix Version" at this point, but please only set a single fix version, the earliest release in which the change will appear. Special case- when committing to a non-mainline branch (such as branch-0.22 or branch-0.23 ATM), please set fix-version to either 2.x.x or 3.x.x appropriately too. ==snip== Yes, this means some discipline (don't set fix version for anything not actually committed, back ports/branch merges have their issues marked appropriately, etc), we should be good. For the most part, we do a pretty good job of this now. [BTW, this also highlights the biggest problem with using pure git log: no matter how you handle it, any program written will need to have the entirety of the git log history for all mainline branches. It would need to compare the commits, build a hash index for any cherry pick resolution, etc, etc. It gets messy fast. The analysis of JIRA is significantly faster, smaller, and easier to write.] I have extremely high confidence that JIRA's knowledge of 2.2->2.6 is correct as of October-ish. 2.6.1 and 2.7 should be in fairly good shape as well. We'd need to verify 2.0.0-alpha->2.1-beta and of course anything missing a FixVersion. There are likely some things marked as 2.0.0-alpha that are actually trunk and not Hadoop 2.0. On 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 >>>>> >>>> >> >>
