hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Akira AJISAKA <ajisa...@oss.nttdata.co.jp>
Subject Re: IMPORTANT: automatic changelog creation
Date Wed, 08 Jul 2015 06:57:11 GMT
+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