+1, thanks Allen and Andrew for taking lots effort! > Is there any possibility that, we can restrict someone from editing the > issue in jira once its marked as "closed" after release?
Vinay's comment looks considerable for us to me. What do you think? - Tsuyoshi On Wed, Jul 8, 2015 at 3:57 PM, Akira AJISAKA <ajisa...@oss.nttdata.co.jp> wrote: > +1, thanks Allen and Andrew. > > Regards, > Akira > > > On 7/3/15 22:31, Devaraj K wrote: >> >> +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 >>>>> >>> >>> >> >> >
