hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsuyoshi Ozawa <oz...@apache.org>
Subject Re: IMPORTANT: automatic changelog creation
Date Wed, 08 Jul 2015 07:13:27 GMT
+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
<ajisakaa@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 <vvasudev@apache.org>
>> wrote:
>>
>>> +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