You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-dev@hadoop.apache.org by Andrew Wang <an...@cloudera.com> on 2015/07/02 23:01:05 UTC
Re: IMPORTANT: automatic changelog creation
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 <sz...@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.
>
>
>
>
Re: IMPORTANT: automatic changelog creation
Posted by Sean Busbey <bu...@cloudera.com>.
On Jul 8, 2015 2:13 AM, "Tsuyoshi Ozawa" <oz...@apache.org> wrote:
>
> +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?
>
Mistakes happen, even during the release process.
Presuming the set of folks who can edit closed tickets is already
restricted to contributors, why not assume any edits are the community
making things more accurate?
--
Sean
Re: IMPORTANT: automatic changelog creation
Posted by Sean Busbey <bu...@cloudera.com>.
On Jul 8, 2015 2:13 AM, "Tsuyoshi Ozawa" <oz...@apache.org> wrote:
>
> +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?
>
Mistakes happen, even during the release process.
Presuming the set of folks who can edit closed tickets is already
restricted to contributors, why not assume any edits are the community
making things more accurate?
--
Sean
Re: IMPORTANT: automatic changelog creation
Posted by Allen Wittenauer <aw...@altiscale.com>.
I think it defeats the purpose ofu
On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
> +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?
If you lock closed liras, then how does re-open work when something gets reverted?
I’m also not sure what purpose it ultimately serves. Is it the fear that the release data that gets shipped with the src tar ball will be wrong? Is it that the data might change? That happens now and is pretty much unfixable no matter what one does. [1] Besides, it’s going to be *extremely* valuable for RMs to be able to edit the JIRA data when cutting a release, especially given how many people are refusing to write release notes for incompatible changes. Being easily audit-able _and easily fixable!_ is a huge win.
It really is a feature that this data can be changed.
Let’s say there is a change. Next release, we can re-roll the old change and release notes data for all releases and it will be correct on the website, etc, from that point on.
FWIW, this is one of the reasons why we really should be publishing trunk’s doc-set to the website. It’s generally more accurate than the last release. Never mind everyone seeming to think that “current” = trunk and getting confused when they write a doc patch that doesn’t apply to trunk.
[1] As part of the JIRA cleanup last year, I added hundreds of JIRAs to 2.0.0-alpha and 0.23.x last year that were incorrectly marked for 0.24 and 3.0.0. I doubt anyone but me (and the future 3.0.0 RM?) really cares.
Re: IMPORTANT: automatic changelog creation
Posted by Allen Wittenauer <aw...@altiscale.com>.
I think it defeats the purpose ofu
On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
> +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?
If you lock closed liras, then how does re-open work when something gets reverted?
I’m also not sure what purpose it ultimately serves. Is it the fear that the release data that gets shipped with the src tar ball will be wrong? Is it that the data might change? That happens now and is pretty much unfixable no matter what one does. [1] Besides, it’s going to be *extremely* valuable for RMs to be able to edit the JIRA data when cutting a release, especially given how many people are refusing to write release notes for incompatible changes. Being easily audit-able _and easily fixable!_ is a huge win.
It really is a feature that this data can be changed.
Let’s say there is a change. Next release, we can re-roll the old change and release notes data for all releases and it will be correct on the website, etc, from that point on.
FWIW, this is one of the reasons why we really should be publishing trunk’s doc-set to the website. It’s generally more accurate than the last release. Never mind everyone seeming to think that “current” = trunk and getting confused when they write a doc patch that doesn’t apply to trunk.
[1] As part of the JIRA cleanup last year, I added hundreds of JIRAs to 2.0.0-alpha and 0.23.x last year that were incorrectly marked for 0.24 and 3.0.0. I doubt anyone but me (and the future 3.0.0 RM?) really cares.
Re: IMPORTANT: automatic changelog creation
Posted by Sean Busbey <bu...@cloudera.com>.
On Jul 8, 2015 2:13 AM, "Tsuyoshi Ozawa" <oz...@apache.org> wrote:
>
> +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?
>
Mistakes happen, even during the release process.
Presuming the set of folks who can edit closed tickets is already
restricted to contributors, why not assume any edits are the community
making things more accurate?
--
Sean
Re: IMPORTANT: automatic changelog creation
Posted by Sean Busbey <bu...@cloudera.com>.
On Jul 8, 2015 2:13 AM, "Tsuyoshi Ozawa" <oz...@apache.org> wrote:
>
> +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?
>
Mistakes happen, even during the release process.
Presuming the set of folks who can edit closed tickets is already
restricted to contributors, why not assume any edits are the community
making things more accurate?
--
Sean
Re: IMPORTANT: automatic changelog creation
Posted by Allen Wittenauer <aw...@altiscale.com>.
I think it defeats the purpose ofu
On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
> +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?
If you lock closed liras, then how does re-open work when something gets reverted?
I’m also not sure what purpose it ultimately serves. Is it the fear that the release data that gets shipped with the src tar ball will be wrong? Is it that the data might change? That happens now and is pretty much unfixable no matter what one does. [1] Besides, it’s going to be *extremely* valuable for RMs to be able to edit the JIRA data when cutting a release, especially given how many people are refusing to write release notes for incompatible changes. Being easily audit-able _and easily fixable!_ is a huge win.
It really is a feature that this data can be changed.
Let’s say there is a change. Next release, we can re-roll the old change and release notes data for all releases and it will be correct on the website, etc, from that point on.
FWIW, this is one of the reasons why we really should be publishing trunk’s doc-set to the website. It’s generally more accurate than the last release. Never mind everyone seeming to think that “current” = trunk and getting confused when they write a doc patch that doesn’t apply to trunk.
[1] As part of the JIRA cleanup last year, I added hundreds of JIRAs to 2.0.0-alpha and 0.23.x last year that were incorrectly marked for 0.24 and 3.0.0. I doubt anyone but me (and the future 3.0.0 RM?) really cares.
Re: IMPORTANT: automatic changelog creation
Posted by Allen Wittenauer <aw...@altiscale.com>.
I think it defeats the purpose ofu
On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa <oz...@apache.org> wrote:
> +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?
If you lock closed liras, then how does re-open work when something gets reverted?
I’m also not sure what purpose it ultimately serves. Is it the fear that the release data that gets shipped with the src tar ball will be wrong? Is it that the data might change? That happens now and is pretty much unfixable no matter what one does. [1] Besides, it’s going to be *extremely* valuable for RMs to be able to edit the JIRA data when cutting a release, especially given how many people are refusing to write release notes for incompatible changes. Being easily audit-able _and easily fixable!_ is a huge win.
It really is a feature that this data can be changed.
Let’s say there is a change. Next release, we can re-roll the old change and release notes data for all releases and it will be correct on the website, etc, from that point on.
FWIW, this is one of the reasons why we really should be publishing trunk’s doc-set to the website. It’s generally more accurate than the last release. Never mind everyone seeming to think that “current” = trunk and getting confused when they write a doc patch that doesn’t apply to trunk.
[1] As part of the JIRA cleanup last year, I added hundreds of JIRAs to 2.0.0-alpha and 0.23.x last year that were incorrectly marked for 0.24 and 3.0.0. I doubt anyone but me (and the future 3.0.0 RM?) really cares.
Re: IMPORTANT: automatic changelog creation
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
+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
<aj...@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 <vv...@apache.org>
>> wrote:
>>
>>> +1
>>>
>>> Many thanks to Allen and Andrew for driving this.
>>>
>>> -Varun
>>>
>>>
>>>
>>> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
>>>
>>> <sz...@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
>>>>>
>>>
>>>
>>
>>
>
Re: IMPORTANT: automatic changelog creation
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
+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
<aj...@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 <vv...@apache.org>
>> wrote:
>>
>>> +1
>>>
>>> Many thanks to Allen and Andrew for driving this.
>>>
>>> -Varun
>>>
>>>
>>>
>>> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
>>>
>>> <sz...@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
>>>>>
>>>
>>>
>>
>>
>
Re: IMPORTANT: automatic changelog creation
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
+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
<aj...@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 <vv...@apache.org>
>> wrote:
>>
>>> +1
>>>
>>> Many thanks to Allen and Andrew for driving this.
>>>
>>> -Varun
>>>
>>>
>>>
>>> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
>>>
>>> <sz...@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
>>>>>
>>>
>>>
>>
>>
>
Re: IMPORTANT: automatic changelog creation
Posted by Tsuyoshi Ozawa <oz...@apache.org>.
+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
<aj...@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 <vv...@apache.org>
>> wrote:
>>
>>> +1
>>>
>>> Many thanks to Allen and Andrew for driving this.
>>>
>>> -Varun
>>>
>>>
>>>
>>> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
>>>
>>> <sz...@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
>>>>>
>>>
>>>
>>
>>
>
Re: IMPORTANT: automatic changelog creation
Posted by Akira AJISAKA <aj...@oss.nttdata.co.jp>.
+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 <vv...@apache.org> wrote:
>
>> +1
>>
>> Many thanks to Allen and Andrew for driving this.
>>
>> -Varun
>>
>>
>>
>> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
>> <sz...@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
>>>>
>>
>>
>
>
Re: IMPORTANT: automatic changelog creation
Posted by Akira AJISAKA <aj...@oss.nttdata.co.jp>.
+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 <vv...@apache.org> wrote:
>
>> +1
>>
>> Many thanks to Allen and Andrew for driving this.
>>
>> -Varun
>>
>>
>>
>> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
>> <sz...@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
>>>>
>>
>>
>
>
Re: IMPORTANT: automatic changelog creation
Posted by Akira AJISAKA <aj...@oss.nttdata.co.jp>.
+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 <vv...@apache.org> wrote:
>
>> +1
>>
>> Many thanks to Allen and Andrew for driving this.
>>
>> -Varun
>>
>>
>>
>> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
>> <sz...@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
>>>>
>>
>>
>
>
Re: IMPORTANT: automatic changelog creation
Posted by Akira AJISAKA <aj...@oss.nttdata.co.jp>.
+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 <vv...@apache.org> wrote:
>
>> +1
>>
>> Many thanks to Allen and Andrew for driving this.
>>
>> -Varun
>>
>>
>>
>> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
>> <sz...@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
>>>>
>>
>>
>
>
Re: IMPORTANT: automatic changelog creation
Posted by Devaraj K <de...@apache.org>.
+1
Thanks Allen and Andrew for your efforts on this.
Thanks
Devaraj
On Fri, Jul 3, 2015 at 11:29 AM, Varun Vasudev <vv...@apache.org> wrote:
> +1
>
> Many thanks to Allen and Andrew for driving this.
>
> -Varun
>
>
>
> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
> <sz...@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
> >>
>
>
--
Thanks
Devaraj K
Re: IMPORTANT: automatic changelog creation
Posted by Devaraj K <de...@apache.org>.
+1
Thanks Allen and Andrew for your efforts on this.
Thanks
Devaraj
On Fri, Jul 3, 2015 at 11:29 AM, Varun Vasudev <vv...@apache.org> wrote:
> +1
>
> Many thanks to Allen and Andrew for driving this.
>
> -Varun
>
>
>
> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
> <sz...@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
> >>
>
>
--
Thanks
Devaraj K
Re: IMPORTANT: automatic changelog creation
Posted by Devaraj K <de...@apache.org>.
+1
Thanks Allen and Andrew for your efforts on this.
Thanks
Devaraj
On Fri, Jul 3, 2015 at 11:29 AM, Varun Vasudev <vv...@apache.org> wrote:
> +1
>
> Many thanks to Allen and Andrew for driving this.
>
> -Varun
>
>
>
> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
> <sz...@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
> >>
>
>
--
Thanks
Devaraj K
Re: IMPORTANT: automatic changelog creation
Posted by Devaraj K <de...@apache.org>.
+1
Thanks Allen and Andrew for your efforts on this.
Thanks
Devaraj
On Fri, Jul 3, 2015 at 11:29 AM, Varun Vasudev <vv...@apache.org> wrote:
> +1
>
> Many thanks to Allen and Andrew for driving this.
>
> -Varun
>
>
>
> On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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
> <sz...@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
> >>
>
>
--
Thanks
Devaraj K
Re: IMPORTANT: automatic changelog creation
Posted by Varun Vasudev <vv...@apache.org>.
+1
Many thanks to Allen and Andrew for driving this.
-Varun
On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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 <sz...@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
>>
Re: IMPORTANT: automatic changelog creation
Posted by Varun Vasudev <vv...@apache.org>.
+1
Many thanks to Allen and Andrew for driving this.
-Varun
On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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 <sz...@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
>>
Re: IMPORTANT: automatic changelog creation
Posted by Varun Vasudev <vv...@apache.org>.
+1
Many thanks to Allen and Andrew for driving this.
-Varun
On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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 <sz...@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
>>
Re: IMPORTANT: automatic changelog creation
Posted by Varun Vasudev <vv...@apache.org>.
+1
Many thanks to Allen and Andrew for driving this.
-Varun
On 7/3/15, 10:25 AM, "Vinayakumar B" <vi...@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 <cn...@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 <sz...@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
>>
Re: IMPORTANT: automatic changelog creation
Posted by Vinayakumar B <vi...@apache.org>.
+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 <cn...@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 <sz...@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
>
Re: IMPORTANT: automatic changelog creation
Posted by Vinayakumar B <vi...@apache.org>.
+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 <cn...@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 <sz...@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
>
Re: IMPORTANT: automatic changelog creation
Posted by Vinayakumar B <vi...@apache.org>.
+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 <cn...@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 <sz...@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
>
Re: IMPORTANT: automatic changelog creation
Posted by Vinayakumar B <vi...@apache.org>.
+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 <cn...@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 <sz...@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
>
Re: IMPORTANT: automatic changelog creation
Posted by Karthik Kambatla <ka...@cloudera.com>.
Huge +1
On Thursday, July 2, 2015, Chris Nauroth <cn...@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 <sz...@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
Re: IMPORTANT: automatic changelog creation
Posted by Karthik Kambatla <ka...@cloudera.com>.
Huge +1
On Thursday, July 2, 2015, Chris Nauroth <cn...@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 <sz...@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
Re: IMPORTANT: automatic changelog creation
Posted by Karthik Kambatla <ka...@cloudera.com>.
Huge +1
On Thursday, July 2, 2015, Chris Nauroth <cn...@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 <sz...@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
Re: IMPORTANT: automatic changelog creation
Posted by Karthik Kambatla <ka...@cloudera.com>.
Huge +1
On Thursday, July 2, 2015, Chris Nauroth <cn...@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 <sz...@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
Re: IMPORTANT: automatic changelog creation
Posted by Chris Nauroth <cn...@hortonworks.com>.
+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" <an...@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 <sz...@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.
>>
>>
>>
>>
Re: IMPORTANT: automatic changelog creation
Posted by Chris Nauroth <cn...@hortonworks.com>.
+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" <an...@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 <sz...@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.
>>
>>
>>
>>
Re: IMPORTANT: automatic changelog creation
Posted by Chris Nauroth <cn...@hortonworks.com>.
+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" <an...@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 <sz...@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.
>>
>>
>>
>>
Re: IMPORTANT: automatic changelog creation
Posted by Chris Nauroth <cn...@hortonworks.com>.
+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" <an...@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 <sz...@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.
>>
>>
>>
>>