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