hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Varun Vasudev <vvasu...@apache.org>
Subject Re: IMPORTANT: automatic changelog creation
Date Fri, 03 Jul 2015 05:59:18 GMT
+1

Many thanks to Allen and Andrew for driving this.

-Varun



On 7/3/15, 10:25 AM, "Vinayakumar B" <vinayakumarb@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 <kasha@cloudera.com> wrote:
>
>> Huge +1
>>
>> On Thursday, July 2, 2015, Chris Nauroth <cnauroth@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.wang@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 <szetszwo@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 <
>> > >> aw@altiscale.com <javascript:;>> wrote:
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
>> > >> vinodkv@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
>>


Mime
View raw message