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