+1 Thanks Allen and Andrew for your efforts on this.
Thanks Devaraj On Fri, Jul 3, 2015 at 11:29 AM, Varun Vasudev <vvasu...@apache.org> wrote: > +1 > > Many thanks to Allen and Andrew for driving this. > > -Varun > > > > On 7/3/15, 10:25 AM, "Vinayakumar B" <vinayakum...@apache.org> wrote: > > >+1 for the auto generation. > > > >bq. Besides, after a release R1 is out, someone may (accidentally or > >intentionally) modify the JIRA summary. > >Is there any possibility that, we can restrict someone from editing the > >issue in jira once its marked as "closed" after release? > > > >Regards, > >Vinay > > > >On Fri, Jul 3, 2015 at 8:32 AM, Karthik Kambatla <ka...@cloudera.com> > wrote: > > > >> 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 > >> > > -- Thanks Devaraj K
