+1 Thank you to Allen for the script, and thank you to Andrew for volunteering to drive the conversion.
--Chris Nauroth On 7/2/15, 2:01 PM, "Andrew Wang" <andrew.w...@cloudera.com> wrote: >Hi all, > >I want to revive the discussion on this thread, since the overhead of >CHANGES.txt came up again in the context of backporting fixes for >maintenance releases. > >Allen's automatic generation script (HADOOP-11731) went into trunk but not >branch-2, so we're still maintaining CHANGES.txt everywhere. What do >people >think about backporting this to branch-2 and then removing CHANGES.txt >from >trunk/branch-2 (HADOOP-11792)? Based on discussion on this thread and in >HADOOP-11731, we seem to agree that CHANGES.txt is an unreliable source of >information, and JIRA is at least as reliable and probably much more so. >Thus I don't see any downsides to backporting it. > >Would like to hear everyone's thoughts on this, I'm willing to drive the >effort. > >Thanks, >Andrew > >On Thu, Apr 2, 2015 at 2:00 PM, Tsz Wo Sze <szets...@yahoo.com.invalid> >wrote: > >> Generating change log from JIRA is a good idea. It bases on an >>assumption >> that each JIRA has an accurate summary (a.k.a. JIRA title) to reflect >>the >> committed change. Unfortunately, the assumption is invalid for many >>cases >> since we never enforce that the JIRA summary must be the same as the >>change >> log. We may compare the current CHANGES.txt with the generated change >> log. I beg the diff is long. >> Besides, after a release R1 is out, someone may (accidentally or >> intentionally) modify the JIRA summary. Then, the entry for the same >>item >> in a later release R2 could be different from the one in R1. >> I agree that manually editing CHANGES.txt is not a perfect solution. >> However, it works well in the past for many releases. I suggest we keep >> the current dev workflow. Try using the new script provided by >> HADOOP-11731 to generate the next release. If everything works well, we >> shell remove CHANGES.txt and revise the dev workflow. What do you >>think? >> Regards,Tsz-Wo >> >> >> On Thursday, April 2, 2015 12:57 PM, Allen Wittenauer < >> a...@altiscale.com> wrote: >> >> >> >> >> >> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli < >> vino...@hortonworks.com> wrote: >> >> > >> > We'd then doing two commits for every patch. Let's simply not remove >> CHANGES.txt from trunk, keep the existing dev workflow, but doc the >>release >> process to remove CHANGES.txt in trunk at the time of a release going >>out >> of trunk. >> >> >> >> Might as well copy branch-2¹s changes.txt into trunk then. (or 2.7¹s. >> Last I looked, people updated branch-2 and not 2.7¹s or vice versa for >>some >> patches that went into both branches.) So that folks who are >>committing to >> both branches and want to cherry pick all changes can. >> >> I mean, trunk¹s is very very very wrong. Right now. Today. Borderline >> useless. See HADOOP-11718 (which I will now close out as won¹t fix)Š and >> that jira is only what is miscategorized, not what is missing. >> >> >> >>
