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. > > > >
