hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Re: IMPORTANT: automatic changelog creation
Date Thu, 02 Jul 2015 21:03:58 GMT
+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> 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> wrote:
>>
>>
>>
>>
>>
>> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
>> vinodkv@hortonworks.com> 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.
>>
>>
>>
>>


Mime
View raw message