Huge +1 On Thursday, July 2, 2015, Chris Nauroth <cnaur...@hortonworks.com> wrote:
> +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 <javascript:;>> > 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 <javascript:;>> wrote: > >> > >> > >> > >> > >> > >> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli < > >> vino...@hortonworks.com <javascript:;>> 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. > >> > >> > >> > >> > > -- Mobile
