You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tez.apache.org by Siddharth Seth <ss...@apache.org> on 2017/03/01 17:35:17 UTC
[DISCUSS] Getting rid of CHANGES.txt
We've been following a process where the Fix Version for any committed jira
is set to include the current version on all branches that the patch goes
to. Given this, I think we can generate a change-list / release notes quite
easily when a release is required.
Before a release, this can easily be looked up via jira, or the commit
history for that matter.
CHANGES.txt at the moment seems to cause conflicts (Pretty much all
cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's also
unnecessary noise, and the file often gets into an inconsistent state, if a
batch is back-ported to a branch after the initial commit to master
(CHANGES.txt on master needs to be updated to commit the patch to an older
branch)
I think we can do without this file at this point. Any reasons to keep it?
Thanks,
Sid
Re: [DISCUSS] Getting rid of CHANGES.txt
Posted by Siddharth Seth <ss...@apache.org>.
Thank you. Will go ahead and file a jira to remove the file from all
branches.
On Wed, Mar 1, 2017 at 9:35 AM, Siddharth Seth <ss...@apache.org> wrote:
> We've been following a process where the Fix Version for any committed
> jira is set to include the current version on all branches that the patch
> goes to. Given this, I think we can generate a change-list / release notes
> quite easily when a release is required.
> Before a release, this can easily be looked up via jira, or the commit
> history for that matter.
>
> CHANGES.txt at the moment seems to cause conflicts (Pretty much all
> cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's also
> unnecessary noise, and the file often gets into an inconsistent state, if a
> batch is back-ported to a branch after the initial commit to master
> (CHANGES.txt on master needs to be updated to commit the patch to an older
> branch)
>
> I think we can do without this file at this point. Any reasons to keep it?
>
> Thanks,
> Sid
>
Re: [DISCUSS] Getting rid of CHANGES.txt
Posted by Sreenath Somarajapuram <sr...@apache.org>.
+1.
Thanks,
Sreenath
On 3/7/17, 8:26 AM, "Rajesh Balamohan" <rb...@apache.org> wrote:
>+1 for the proposal. IIRC, projects like hadoop, hive etc do not update
>changes.txt.
>
>~Rajesh.B
>
>On Tue, Mar 7, 2017 at 7:44 AM, Siddharth Seth <ss...@apache.org> wrote:
>
>> Anyone? I'll create a jira to get rid of the this file otherwise.
>>
>> On Wed, Mar 1, 2017 at 9:35 AM, Siddharth Seth <ss...@apache.org> wrote:
>>
>> > We've been following a process where the Fix Version for any committed
>> > jira is set to include the current version on all branches that the
>>patch
>> > goes to. Given this, I think we can generate a change-list / release
>> notes
>> > quite easily when a release is required.
>> > Before a release, this can easily be looked up via jira, or the commit
>> > history for that matter.
>> >
>> > CHANGES.txt at the moment seems to cause conflicts (Pretty much all
>> > cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's
>> also
>> > unnecessary noise, and the file often gets into an inconsistent state,
>> if a
>> > batch is back-ported to a branch after the initial commit to master
>> > (CHANGES.txt on master needs to be updated to commit the patch to an
>> older
>> > branch)
>> >
>> > I think we can do without this file at this point. Any reasons to keep
>> it?
>> >
>> > Thanks,
>> > Sid
>> >
>>
Re: [DISCUSS] Getting rid of CHANGES.txt
Posted by Rajesh Balamohan <rb...@apache.org>.
+1 for the proposal. IIRC, projects like hadoop, hive etc do not update
changes.txt.
~Rajesh.B
On Tue, Mar 7, 2017 at 7:44 AM, Siddharth Seth <ss...@apache.org> wrote:
> Anyone? I'll create a jira to get rid of the this file otherwise.
>
> On Wed, Mar 1, 2017 at 9:35 AM, Siddharth Seth <ss...@apache.org> wrote:
>
> > We've been following a process where the Fix Version for any committed
> > jira is set to include the current version on all branches that the patch
> > goes to. Given this, I think we can generate a change-list / release
> notes
> > quite easily when a release is required.
> > Before a release, this can easily be looked up via jira, or the commit
> > history for that matter.
> >
> > CHANGES.txt at the moment seems to cause conflicts (Pretty much all
> > cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's
> also
> > unnecessary noise, and the file often gets into an inconsistent state,
> if a
> > batch is back-ported to a branch after the initial commit to master
> > (CHANGES.txt on master needs to be updated to commit the patch to an
> older
> > branch)
> >
> > I think we can do without this file at this point. Any reasons to keep
> it?
> >
> > Thanks,
> > Sid
> >
>
Re: [DISCUSS] Getting rid of CHANGES.txt
Posted by Siddharth Seth <ss...@apache.org>.
Anyone? I'll create a jira to get rid of the this file otherwise.
On Wed, Mar 1, 2017 at 9:35 AM, Siddharth Seth <ss...@apache.org> wrote:
> We've been following a process where the Fix Version for any committed
> jira is set to include the current version on all branches that the patch
> goes to. Given this, I think we can generate a change-list / release notes
> quite easily when a release is required.
> Before a release, this can easily be looked up via jira, or the commit
> history for that matter.
>
> CHANGES.txt at the moment seems to cause conflicts (Pretty much all
> cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's also
> unnecessary noise, and the file often gets into an inconsistent state, if a
> batch is back-ported to a branch after the initial commit to master
> (CHANGES.txt on master needs to be updated to commit the patch to an older
> branch)
>
> I think we can do without this file at this point. Any reasons to keep it?
>
> Thanks,
> Sid
>
RE: [DISCUSS] Getting rid of CHANGES.txt
Posted by Bikas Saha <bi...@outlook.com>.
+1
-----Original Message-----
From: Kuhu Shukla [mailto:kshukla@yahoo-inc.com.INVALID]
Sent: Monday, March 13, 2017 6:17 AM
To: dev@tez.apache.org; Harish JP <hj...@hortonworks.com>; dev@tez.apache.org
Subject: Re: [DISCUSS] Getting rid of CHANGES.txt
+1 non binding.
Sent from Yahoo Mail on Android
On Sun, Mar 12, 2017 at 10:51 PM, Harish JP<hj...@hortonworks.com> wrote: +1.
On 13-Mar-2017, at 9:19 AM, Jonathan Eagles <je...@gmail.com> wrote:
+1 All in favor of this.
On Wed, Mar 1, 2017 at 11:35 AM, Siddharth Seth <ss...@apache.org> wrote:
> We've been following a process where the Fix Version for any committed
> jira is set to include the current version on all branches that the
> patch goes to. Given this, I think we can generate a change-list /
> release notes quite easily when a release is required.
> Before a release, this can easily be looked up via jira, or the commit
> history for that matter.
>
> CHANGES.txt at the moment seems to cause conflicts (Pretty much all
> cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's
> also unnecessary noise, and the file often gets into an inconsistent
> state, if a batch is back-ported to a branch after the initial commit
> to master (CHANGES.txt on master needs to be updated to commit the
> patch to an older
> branch)
>
> I think we can do without this file at this point. Any reasons to keep it?
>
> Thanks,
> Sid
Re: [DISCUSS] Getting rid of CHANGES.txt
Posted by Kuhu Shukla <ks...@yahoo-inc.com.INVALID>.
+1 non binding.
Sent from Yahoo Mail on Android
On Sun, Mar 12, 2017 at 10:51 PM, Harish JP<hj...@hortonworks.com> wrote: +1.
On 13-Mar-2017, at 9:19 AM, Jonathan Eagles <je...@gmail.com> wrote:
+1 All in favor of this.
On Wed, Mar 1, 2017 at 11:35 AM, Siddharth Seth <ss...@apache.org> wrote:
> We've been following a process where the Fix Version for any committed jira
> is set to include the current version on all branches that the patch goes
> to. Given this, I think we can generate a change-list / release notes quite
> easily when a release is required.
> Before a release, this can easily be looked up via jira, or the commit
> history for that matter.
>
> CHANGES.txt at the moment seems to cause conflicts (Pretty much all
> cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's also
> unnecessary noise, and the file often gets into an inconsistent state, if a
> batch is back-ported to a branch after the initial commit to master
> (CHANGES.txt on master needs to be updated to commit the patch to an older
> branch)
>
> I think we can do without this file at this point. Any reasons to keep it?
>
> Thanks,
> Sid
Re: [DISCUSS] Getting rid of CHANGES.txt
Posted by Harish JP <hj...@hortonworks.com>.
+1.
On 13-Mar-2017, at 9:19 AM, Jonathan Eagles <je...@gmail.com> wrote:
+1 All in favor of this.
On Wed, Mar 1, 2017 at 11:35 AM, Siddharth Seth <ss...@apache.org> wrote:
> We've been following a process where the Fix Version for any committed jira
> is set to include the current version on all branches that the patch goes
> to. Given this, I think we can generate a change-list / release notes quite
> easily when a release is required.
> Before a release, this can easily be looked up via jira, or the commit
> history for that matter.
>
> CHANGES.txt at the moment seems to cause conflicts (Pretty much all
> cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's also
> unnecessary noise, and the file often gets into an inconsistent state, if a
> batch is back-ported to a branch after the initial commit to master
> (CHANGES.txt on master needs to be updated to commit the patch to an older
> branch)
>
> I think we can do without this file at this point. Any reasons to keep it?
>
> Thanks,
> Sid
Re: [DISCUSS] Getting rid of CHANGES.txt
Posted by Jonathan Eagles <je...@gmail.com>.
+1 All in favor of this.
On Wed, Mar 1, 2017 at 11:35 AM, Siddharth Seth <ss...@apache.org> wrote:
> We've been following a process where the Fix Version for any committed jira
> is set to include the current version on all branches that the patch goes
> to. Given this, I think we can generate a change-list / release notes quite
> easily when a release is required.
> Before a release, this can easily be looked up via jira, or the commit
> history for that matter.
>
> CHANGES.txt at the moment seems to cause conflicts (Pretty much all
> cherry-picks on branch-0.8 will have a CHANGES.txt conflict). There's also
> unnecessary noise, and the file often gets into an inconsistent state, if a
> batch is back-ported to a branch after the initial commit to master
> (CHANGES.txt on master needs to be updated to commit the patch to an older
> branch)
>
> I think we can do without this file at this point. Any reasons to keep it?
>
> Thanks,
> Sid
>