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 Akira AJISAKA <aj...@oss.nttdata.co.jp> on 2016/01/08 17:43:18 UTC
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
The general rule sounds good to me.
> "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
get out after 2.x.y release date"
+1
> I would prefer this rule only applies on critical/blocker fixes, but
not applies on minor/trivial issues.
+1
Thanks,
Akira
On 12/29/15 23:50, Junping Du wrote:
> I am +1 with pulling all of these tickets into 2.7.2.
>
> - For “any fix in 2.6.3 to be there in all releases that get out after 2.6.3 release date”
>
> Shall we conclude this as a general rule - "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"? I am generally fine with this, but just feel it sounds to set too strong restrictions among branches. Some fixes could be trivial (test case fix, etc.) enough to deserve more flexibility. I would prefer this rule only applies on critical/blocker fixes, but not applies on minor/trivial issues.
>
> Just 2 cents.
>
>
> Thanks,
>
>
> Junping
>
>
> ________________________________
> From: Vinod Kumar Vavilapalli <vi...@apache.org>
> Sent: Thursday, December 24, 2015 12:47 AM
> To: Junping Du
> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>
> I retract my -1. I think we will need to discuss this a bit more.
>
> Beyond those two tickets, there are a bunch more (totaling to 16) that are in 2.6.3 but *not* in 2.7.2. See this: https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0<https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0>
>
> Two options here, depending on the importance of ‘causality' between 2.6.x and 2.7.x lines.
> - Ship 2.7.2 as we voted on here
> - Pull these 16 tickets into 2.7.2 and roll a new RC
>
> What do people think? Do folks expect “any fix in 2.6.3 to be there in all releases that get out after 2.6.3 release date (December 16th)”?
>
> Thanks
> +Vinod
>
> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vi...@apache.org>> wrote:
>
> Sigh. Missed this.
>
> To retain causality ("any fix in 2.6.3 will be there in all releases that got out after 2.6.3”), I’ll get these patches in.
>
> Reverting my +1, and casting -1 for the RC myself.
>
> Will spin a new RC, this voting thread is marked dead.
>
> Thanks
> +Vinod
>
> On Dec 22, 2015, at 8:24 AM, Junping Du <jd...@hortonworks.com>> wrote:
>
> However, when I look at our commit log and CHANGES.txt, I found something we are missing:
> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Andrew Wang <an...@cloudera.com>.
On Mon, Jan 11, 2016 at 7:22 AM, Junping Du <jd...@hortonworks.com> wrote:
> bq. Is it difficult to backport to 2.7.x if you're already backporting to
> 2.6.x? I don't follow why special casing some class of fixes is desirable.
> It is not difficult to backport the commits between 2.6.x and 2.7.x.
> However, it do *difficult* to track exactly for hundreds of commits between
> them. Taking HDFS-9470 as an example, the committer totally forget to merge
> the commit into 2.7.2 when it is resolved as fixed in 2.7.2. The commit was
> merged into 2.6.3 later but get missed on 2.7.2 RC1. If this is not a
> critical fix, I don't think 2.7.2 should get a new RC to wait this commit
> to land on. That's why classifying on priority of fixes are important and
> desirable when we are facing this situation.
>
> Gotcha, so this in this case it is the exception and not the rule? I'd
still rather the rule be simple, and then exceptions like this addressed on
a case-by-case basis.
Colin also wrote a branch-diff tool that looks at git log, which makes
tracking easier. You can do things like diff 2.6.0 with 2.6.3, 2.7.0 with
2.7.2, and then make sure that the 2.7 diff is a superset of 2.6.
https://github.com/cmccabe/cmccabe-hbin/blob/master/jirafun.go
Wouldn't be the worst idea to make this part of our release validation
process. The report could be automated as a Jenkins job.
> bq. Also for maintenance releases, aren't all included fixes supposed to
> be for serious bugs? Minor JIRAs can wait for the next minor release. If
> there are strong reasons to include a minor JIRA in a maintenance release,
> then maybe it's not really a minor JIRA.
> If a committer commit a major/minor priority patch on a maintenance
> release, what RM should do? Revert it or upgrade the priority to critical
> even it doesn't belong to critical?
> I believe only commit critical/blocker patch to maintenance release can
> only be a general guideline for maintenance release, but not a strict rule
> for all committers in practice. RMs should obey this guideline strictly in
> cherry-pick commits but there are more commits get committed by other
> committers. The committer choose the fixed branch not only by priority but
> also by target branch proposed by patch contributor who may only work on
> that branch release for a long time. I think this target/fix branch
> negotiation mechanism going on well and we shouldn't break it.
>
> This sounds like another reminder for everyone to:
- Please be judicious about what gets backported to maintenance releases.
- When backporting, please backport to all intermediate maintenance
branches.
Based on what I've seen, the RMs have been very responsive, so the safest
thing is to ping them about inclusion before backporting. I'd be in favor
of a guideline like "get an RM to +1 before backporting."
Best,
Andrew
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Sangjin Lee <sj...@apache.org>.
I agree that it would be a good practice to maintain parity between 2.6.x
and 2.7.x as much as possible. Departure from it should be more of an
exception than the norm.
That said, it is also true that we're not exactly following the semantic
versioning the moment we started to maintain multiple simultaneous release
branches. In semantic versioning, the timing of the release doesn't really
matter. If we were following semantic versioning, all releases in 2.6.x
would be considered "earlier versions" than 2.7.x regardless of their
release time. Obviously we cannot ensure no regression in that situation.
FWIW.
On Fri, Jan 8, 2016 at 11:43 AM, Andrew Wang <an...@cloudera.com>
wrote:
> I like monotonic releases since it's simple for users to understand. Is it
> difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
> don't follow why special casing some class of fixes is desirable.
>
> Also for maintenance releases, aren't all included fixes supposed to be for
> serious bugs? Minor JIRAs can wait for the next minor release. If there are
> strong reasons to include a minor JIRA in a maintenance release, then maybe
> it's not really a minor JIRA.
>
> Best,
> Andrew
>
> On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
> wrote:
>
> > The general rule sounds good to me.
> >
> > > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> > get out after 2.x.y release date"
> >
> > +1
> >
> > > I would prefer this rule only applies on critical/blocker fixes, but
> not
> > applies on minor/trivial issues.
> >
> > +1
> >
> > Thanks,
> > Akira
> >
> >
> > On 12/29/15 23:50, Junping Du wrote:
> >
> >> I am +1 with pulling all of these tickets into 2.7.2.
> >>
> >> - For “any fix in 2.6.3 to be there in all releases that get out after
> >> 2.6.3 release date”
> >>
> >> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
> >> in all 2.b.c releases (while b>=x) that get out after 2.x.y release
> date"?
> >> I am generally fine with this, but just feel it sounds to set too strong
> >> restrictions among branches. Some fixes could be trivial (test case fix,
> >> etc.) enough to deserve more flexibility. I would prefer this rule only
> >> applies on critical/blocker fixes, but not applies on minor/trivial
> issues.
> >>
> >> Just 2 cents.
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Junping
> >>
> >>
> >> ________________________________
> >> From: Vinod Kumar Vavilapalli <vi...@apache.org>
> >> Sent: Thursday, December 24, 2015 12:47 AM
> >> To: Junping Du
> >> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> >> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
> >> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
> >>
> >> I retract my -1. I think we will need to discuss this a bit more.
> >>
> >> Beyond those two tickets, there are a bunch more (totaling to 16) that
> >> are in 2.6.3 but *not* in 2.7.2. See this:
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
> >> <
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
> >> >
> >>
> >> Two options here, depending on the importance of ‘causality' between
> >> 2.6.x and 2.7.x lines.
> >> - Ship 2.7.2 as we voted on here
> >> - Pull these 16 tickets into 2.7.2 and roll a new RC
> >>
> >> What do people think? Do folks expect “any fix in 2.6.3 to be there in
> >> all releases that get out after 2.6.3 release date (December 16th)”?
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org
> >> <ma...@apache.org>> wrote:
> >>
> >> Sigh. Missed this.
> >>
> >> To retain causality ("any fix in 2.6.3 will be there in all releases
> that
> >> got out after 2.6.3”), I’ll get these patches in.
> >>
> >> Reverting my +1, and casting -1 for the RC myself.
> >>
> >> Will spin a new RC, this voting thread is marked dead.
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
> >> jdu@hortonworks.com>> wrote:
> >>
> >> However, when I look at our commit log and CHANGES.txt, I found
> something
> >> we are missing:
> >> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1
> tag.
> >> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
> >>
> >>
> >>
> >
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Sangjin Lee <sj...@apache.org>.
I agree that it would be a good practice to maintain parity between 2.6.x
and 2.7.x as much as possible. Departure from it should be more of an
exception than the norm.
That said, it is also true that we're not exactly following the semantic
versioning the moment we started to maintain multiple simultaneous release
branches. In semantic versioning, the timing of the release doesn't really
matter. If we were following semantic versioning, all releases in 2.6.x
would be considered "earlier versions" than 2.7.x regardless of their
release time. Obviously we cannot ensure no regression in that situation.
FWIW.
On Fri, Jan 8, 2016 at 11:43 AM, Andrew Wang <an...@cloudera.com>
wrote:
> I like monotonic releases since it's simple for users to understand. Is it
> difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
> don't follow why special casing some class of fixes is desirable.
>
> Also for maintenance releases, aren't all included fixes supposed to be for
> serious bugs? Minor JIRAs can wait for the next minor release. If there are
> strong reasons to include a minor JIRA in a maintenance release, then maybe
> it's not really a minor JIRA.
>
> Best,
> Andrew
>
> On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
> wrote:
>
> > The general rule sounds good to me.
> >
> > > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> > get out after 2.x.y release date"
> >
> > +1
> >
> > > I would prefer this rule only applies on critical/blocker fixes, but
> not
> > applies on minor/trivial issues.
> >
> > +1
> >
> > Thanks,
> > Akira
> >
> >
> > On 12/29/15 23:50, Junping Du wrote:
> >
> >> I am +1 with pulling all of these tickets into 2.7.2.
> >>
> >> - For “any fix in 2.6.3 to be there in all releases that get out after
> >> 2.6.3 release date”
> >>
> >> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
> >> in all 2.b.c releases (while b>=x) that get out after 2.x.y release
> date"?
> >> I am generally fine with this, but just feel it sounds to set too strong
> >> restrictions among branches. Some fixes could be trivial (test case fix,
> >> etc.) enough to deserve more flexibility. I would prefer this rule only
> >> applies on critical/blocker fixes, but not applies on minor/trivial
> issues.
> >>
> >> Just 2 cents.
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Junping
> >>
> >>
> >> ________________________________
> >> From: Vinod Kumar Vavilapalli <vi...@apache.org>
> >> Sent: Thursday, December 24, 2015 12:47 AM
> >> To: Junping Du
> >> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> >> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
> >> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
> >>
> >> I retract my -1. I think we will need to discuss this a bit more.
> >>
> >> Beyond those two tickets, there are a bunch more (totaling to 16) that
> >> are in 2.6.3 but *not* in 2.7.2. See this:
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
> >> <
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
> >> >
> >>
> >> Two options here, depending on the importance of ‘causality' between
> >> 2.6.x and 2.7.x lines.
> >> - Ship 2.7.2 as we voted on here
> >> - Pull these 16 tickets into 2.7.2 and roll a new RC
> >>
> >> What do people think? Do folks expect “any fix in 2.6.3 to be there in
> >> all releases that get out after 2.6.3 release date (December 16th)”?
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org
> >> <ma...@apache.org>> wrote:
> >>
> >> Sigh. Missed this.
> >>
> >> To retain causality ("any fix in 2.6.3 will be there in all releases
> that
> >> got out after 2.6.3”), I’ll get these patches in.
> >>
> >> Reverting my +1, and casting -1 for the RC myself.
> >>
> >> Will spin a new RC, this voting thread is marked dead.
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
> >> jdu@hortonworks.com>> wrote:
> >>
> >> However, when I look at our commit log and CHANGES.txt, I found
> something
> >> we are missing:
> >> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1
> tag.
> >> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
> >>
> >>
> >>
> >
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Sangjin Lee <sj...@apache.org>.
I agree that it would be a good practice to maintain parity between 2.6.x
and 2.7.x as much as possible. Departure from it should be more of an
exception than the norm.
That said, it is also true that we're not exactly following the semantic
versioning the moment we started to maintain multiple simultaneous release
branches. In semantic versioning, the timing of the release doesn't really
matter. If we were following semantic versioning, all releases in 2.6.x
would be considered "earlier versions" than 2.7.x regardless of their
release time. Obviously we cannot ensure no regression in that situation.
FWIW.
On Fri, Jan 8, 2016 at 11:43 AM, Andrew Wang <an...@cloudera.com>
wrote:
> I like monotonic releases since it's simple for users to understand. Is it
> difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
> don't follow why special casing some class of fixes is desirable.
>
> Also for maintenance releases, aren't all included fixes supposed to be for
> serious bugs? Minor JIRAs can wait for the next minor release. If there are
> strong reasons to include a minor JIRA in a maintenance release, then maybe
> it's not really a minor JIRA.
>
> Best,
> Andrew
>
> On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
> wrote:
>
> > The general rule sounds good to me.
> >
> > > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> > get out after 2.x.y release date"
> >
> > +1
> >
> > > I would prefer this rule only applies on critical/blocker fixes, but
> not
> > applies on minor/trivial issues.
> >
> > +1
> >
> > Thanks,
> > Akira
> >
> >
> > On 12/29/15 23:50, Junping Du wrote:
> >
> >> I am +1 with pulling all of these tickets into 2.7.2.
> >>
> >> - For “any fix in 2.6.3 to be there in all releases that get out after
> >> 2.6.3 release date”
> >>
> >> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
> >> in all 2.b.c releases (while b>=x) that get out after 2.x.y release
> date"?
> >> I am generally fine with this, but just feel it sounds to set too strong
> >> restrictions among branches. Some fixes could be trivial (test case fix,
> >> etc.) enough to deserve more flexibility. I would prefer this rule only
> >> applies on critical/blocker fixes, but not applies on minor/trivial
> issues.
> >>
> >> Just 2 cents.
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Junping
> >>
> >>
> >> ________________________________
> >> From: Vinod Kumar Vavilapalli <vi...@apache.org>
> >> Sent: Thursday, December 24, 2015 12:47 AM
> >> To: Junping Du
> >> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> >> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
> >> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
> >>
> >> I retract my -1. I think we will need to discuss this a bit more.
> >>
> >> Beyond those two tickets, there are a bunch more (totaling to 16) that
> >> are in 2.6.3 but *not* in 2.7.2. See this:
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
> >> <
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
> >> >
> >>
> >> Two options here, depending on the importance of ‘causality' between
> >> 2.6.x and 2.7.x lines.
> >> - Ship 2.7.2 as we voted on here
> >> - Pull these 16 tickets into 2.7.2 and roll a new RC
> >>
> >> What do people think? Do folks expect “any fix in 2.6.3 to be there in
> >> all releases that get out after 2.6.3 release date (December 16th)”?
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org
> >> <ma...@apache.org>> wrote:
> >>
> >> Sigh. Missed this.
> >>
> >> To retain causality ("any fix in 2.6.3 will be there in all releases
> that
> >> got out after 2.6.3”), I’ll get these patches in.
> >>
> >> Reverting my +1, and casting -1 for the RC myself.
> >>
> >> Will spin a new RC, this voting thread is marked dead.
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
> >> jdu@hortonworks.com>> wrote:
> >>
> >> However, when I look at our commit log and CHANGES.txt, I found
> something
> >> we are missing:
> >> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1
> tag.
> >> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
> >>
> >>
> >>
> >
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Sangjin Lee <sj...@apache.org>.
I agree that it would be a good practice to maintain parity between 2.6.x
and 2.7.x as much as possible. Departure from it should be more of an
exception than the norm.
That said, it is also true that we're not exactly following the semantic
versioning the moment we started to maintain multiple simultaneous release
branches. In semantic versioning, the timing of the release doesn't really
matter. If we were following semantic versioning, all releases in 2.6.x
would be considered "earlier versions" than 2.7.x regardless of their
release time. Obviously we cannot ensure no regression in that situation.
FWIW.
On Fri, Jan 8, 2016 at 11:43 AM, Andrew Wang <an...@cloudera.com>
wrote:
> I like monotonic releases since it's simple for users to understand. Is it
> difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
> don't follow why special casing some class of fixes is desirable.
>
> Also for maintenance releases, aren't all included fixes supposed to be for
> serious bugs? Minor JIRAs can wait for the next minor release. If there are
> strong reasons to include a minor JIRA in a maintenance release, then maybe
> it's not really a minor JIRA.
>
> Best,
> Andrew
>
> On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
> wrote:
>
> > The general rule sounds good to me.
> >
> > > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> > get out after 2.x.y release date"
> >
> > +1
> >
> > > I would prefer this rule only applies on critical/blocker fixes, but
> not
> > applies on minor/trivial issues.
> >
> > +1
> >
> > Thanks,
> > Akira
> >
> >
> > On 12/29/15 23:50, Junping Du wrote:
> >
> >> I am +1 with pulling all of these tickets into 2.7.2.
> >>
> >> - For “any fix in 2.6.3 to be there in all releases that get out after
> >> 2.6.3 release date”
> >>
> >> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
> >> in all 2.b.c releases (while b>=x) that get out after 2.x.y release
> date"?
> >> I am generally fine with this, but just feel it sounds to set too strong
> >> restrictions among branches. Some fixes could be trivial (test case fix,
> >> etc.) enough to deserve more flexibility. I would prefer this rule only
> >> applies on critical/blocker fixes, but not applies on minor/trivial
> issues.
> >>
> >> Just 2 cents.
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Junping
> >>
> >>
> >> ________________________________
> >> From: Vinod Kumar Vavilapalli <vi...@apache.org>
> >> Sent: Thursday, December 24, 2015 12:47 AM
> >> To: Junping Du
> >> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
> >> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
> >> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
> >>
> >> I retract my -1. I think we will need to discuss this a bit more.
> >>
> >> Beyond those two tickets, there are a bunch more (totaling to 16) that
> >> are in 2.6.3 but *not* in 2.7.2. See this:
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
> >> <
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
> >> >
> >>
> >> Two options here, depending on the importance of ‘causality' between
> >> 2.6.x and 2.7.x lines.
> >> - Ship 2.7.2 as we voted on here
> >> - Pull these 16 tickets into 2.7.2 and roll a new RC
> >>
> >> What do people think? Do folks expect “any fix in 2.6.3 to be there in
> >> all releases that get out after 2.6.3 release date (December 16th)”?
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <
> vinodkv@apache.org
> >> <ma...@apache.org>> wrote:
> >>
> >> Sigh. Missed this.
> >>
> >> To retain causality ("any fix in 2.6.3 will be there in all releases
> that
> >> got out after 2.6.3”), I’ll get these patches in.
> >>
> >> Reverting my +1, and casting -1 for the RC myself.
> >>
> >> Will spin a new RC, this voting thread is marked dead.
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
> >> jdu@hortonworks.com>> wrote:
> >>
> >> However, when I look at our commit log and CHANGES.txt, I found
> something
> >> we are missing:
> >> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1
> tag.
> >> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
> >>
> >>
> >>
> >
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Junping Du <jd...@hortonworks.com>.
bq. Is it difficult to backport to 2.7.x if you're already backporting to 2.6.x? I don't follow why special casing some class of fixes is desirable.
It is not difficult to backport the commits between 2.6.x and 2.7.x. However, it do *difficult* to track exactly for hundreds of commits between them. Taking HDFS-9470 as an example, the committer totally forget to merge the commit into 2.7.2 when it is resolved as fixed in 2.7.2. The commit was merged into 2.6.3 later but get missed on 2.7.2 RC1. If this is not a critical fix, I don't think 2.7.2 should get a new RC to wait this commit to land on. That's why classifying on priority of fixes are important and desirable when we are facing this situation.
bq. Also for maintenance releases, aren't all included fixes supposed to be for serious bugs? Minor JIRAs can wait for the next minor release. If there are strong reasons to include a minor JIRA in a maintenance release, then maybe it's not really a minor JIRA.
If a committer commit a major/minor priority patch on a maintenance release, what RM should do? Revert it or upgrade the priority to critical even it doesn't belong to critical?
I believe only commit critical/blocker patch to maintenance release can only be a general guideline for maintenance release, but not a strict rule for all committers in practice. RMs should obey this guideline strictly in cherry-pick commits but there are more commits get committed by other committers. The committer choose the fixed branch not only by priority but also by target branch proposed by patch contributor who may only work on that branch release for a long time. I think this target/fix branch negotiation mechanism going on well and we shouldn't break it.
Thanks,
Junping
________________________________________
From: Andrew Wang <an...@cloudera.com>
Sent: Friday, January 08, 2016 7:43 PM
To: common-dev@hadoop.apache.org
Cc: mapreduce-dev@hadoop.apache.org; Vinod Kumar Vavilapalli; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.
Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.
Best,
Andrew
On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
wrote:
> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but not
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For “any fix in 2.6.3 to be there in all releases that get out after
>> 2.6.3 release date”
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility. I would prefer this rule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issues.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> ________________________________
>> From: Vinod Kumar Vavilapalli <vi...@apache.org>
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
>> >
>>
>> Two options here, depending on the importance of ‘causality' between
>> 2.6.x and 2.7.x lines.
>> - Ship 2.7.2 as we voted on here
>> - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect “any fix in 2.6.3 to be there in
>> all releases that get out after 2.6.3 release date (December 16th)”?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases that
>> got out after 2.6.3”), I’ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
>> jdu@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found something
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Junping Du <jd...@hortonworks.com>.
bq. Is it difficult to backport to 2.7.x if you're already backporting to 2.6.x? I don't follow why special casing some class of fixes is desirable.
It is not difficult to backport the commits between 2.6.x and 2.7.x. However, it do *difficult* to track exactly for hundreds of commits between them. Taking HDFS-9470 as an example, the committer totally forget to merge the commit into 2.7.2 when it is resolved as fixed in 2.7.2. The commit was merged into 2.6.3 later but get missed on 2.7.2 RC1. If this is not a critical fix, I don't think 2.7.2 should get a new RC to wait this commit to land on. That's why classifying on priority of fixes are important and desirable when we are facing this situation.
bq. Also for maintenance releases, aren't all included fixes supposed to be for serious bugs? Minor JIRAs can wait for the next minor release. If there are strong reasons to include a minor JIRA in a maintenance release, then maybe it's not really a minor JIRA.
If a committer commit a major/minor priority patch on a maintenance release, what RM should do? Revert it or upgrade the priority to critical even it doesn't belong to critical?
I believe only commit critical/blocker patch to maintenance release can only be a general guideline for maintenance release, but not a strict rule for all committers in practice. RMs should obey this guideline strictly in cherry-pick commits but there are more commits get committed by other committers. The committer choose the fixed branch not only by priority but also by target branch proposed by patch contributor who may only work on that branch release for a long time. I think this target/fix branch negotiation mechanism going on well and we shouldn't break it.
Thanks,
Junping
________________________________________
From: Andrew Wang <an...@cloudera.com>
Sent: Friday, January 08, 2016 7:43 PM
To: common-dev@hadoop.apache.org
Cc: mapreduce-dev@hadoop.apache.org; Vinod Kumar Vavilapalli; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.
Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.
Best,
Andrew
On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
wrote:
> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but not
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For “any fix in 2.6.3 to be there in all releases that get out after
>> 2.6.3 release date”
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility. I would prefer this rule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issues.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> ________________________________
>> From: Vinod Kumar Vavilapalli <vi...@apache.org>
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
>> >
>>
>> Two options here, depending on the importance of ‘causality' between
>> 2.6.x and 2.7.x lines.
>> - Ship 2.7.2 as we voted on here
>> - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect “any fix in 2.6.3 to be there in
>> all releases that get out after 2.6.3 release date (December 16th)”?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases that
>> got out after 2.6.3”), I’ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
>> jdu@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found something
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Junping Du <jd...@hortonworks.com>.
bq. Is it difficult to backport to 2.7.x if you're already backporting to 2.6.x? I don't follow why special casing some class of fixes is desirable.
It is not difficult to backport the commits between 2.6.x and 2.7.x. However, it do *difficult* to track exactly for hundreds of commits between them. Taking HDFS-9470 as an example, the committer totally forget to merge the commit into 2.7.2 when it is resolved as fixed in 2.7.2. The commit was merged into 2.6.3 later but get missed on 2.7.2 RC1. If this is not a critical fix, I don't think 2.7.2 should get a new RC to wait this commit to land on. That's why classifying on priority of fixes are important and desirable when we are facing this situation.
bq. Also for maintenance releases, aren't all included fixes supposed to be for serious bugs? Minor JIRAs can wait for the next minor release. If there are strong reasons to include a minor JIRA in a maintenance release, then maybe it's not really a minor JIRA.
If a committer commit a major/minor priority patch on a maintenance release, what RM should do? Revert it or upgrade the priority to critical even it doesn't belong to critical?
I believe only commit critical/blocker patch to maintenance release can only be a general guideline for maintenance release, but not a strict rule for all committers in practice. RMs should obey this guideline strictly in cherry-pick commits but there are more commits get committed by other committers. The committer choose the fixed branch not only by priority but also by target branch proposed by patch contributor who may only work on that branch release for a long time. I think this target/fix branch negotiation mechanism going on well and we shouldn't break it.
Thanks,
Junping
________________________________________
From: Andrew Wang <an...@cloudera.com>
Sent: Friday, January 08, 2016 7:43 PM
To: common-dev@hadoop.apache.org
Cc: mapreduce-dev@hadoop.apache.org; Vinod Kumar Vavilapalli; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.
Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.
Best,
Andrew
On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
wrote:
> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but not
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For “any fix in 2.6.3 to be there in all releases that get out after
>> 2.6.3 release date”
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility. I would prefer this rule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issues.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> ________________________________
>> From: Vinod Kumar Vavilapalli <vi...@apache.org>
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
>> >
>>
>> Two options here, depending on the importance of ‘causality' between
>> 2.6.x and 2.7.x lines.
>> - Ship 2.7.2 as we voted on here
>> - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect “any fix in 2.6.3 to be there in
>> all releases that get out after 2.6.3 release date (December 16th)”?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases that
>> got out after 2.6.3”), I’ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
>> jdu@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found something
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Junping Du <jd...@hortonworks.com>.
bq. Is it difficult to backport to 2.7.x if you're already backporting to 2.6.x? I don't follow why special casing some class of fixes is desirable.
It is not difficult to backport the commits between 2.6.x and 2.7.x. However, it do *difficult* to track exactly for hundreds of commits between them. Taking HDFS-9470 as an example, the committer totally forget to merge the commit into 2.7.2 when it is resolved as fixed in 2.7.2. The commit was merged into 2.6.3 later but get missed on 2.7.2 RC1. If this is not a critical fix, I don't think 2.7.2 should get a new RC to wait this commit to land on. That's why classifying on priority of fixes are important and desirable when we are facing this situation.
bq. Also for maintenance releases, aren't all included fixes supposed to be for serious bugs? Minor JIRAs can wait for the next minor release. If there are strong reasons to include a minor JIRA in a maintenance release, then maybe it's not really a minor JIRA.
If a committer commit a major/minor priority patch on a maintenance release, what RM should do? Revert it or upgrade the priority to critical even it doesn't belong to critical?
I believe only commit critical/blocker patch to maintenance release can only be a general guideline for maintenance release, but not a strict rule for all committers in practice. RMs should obey this guideline strictly in cherry-pick commits but there are more commits get committed by other committers. The committer choose the fixed branch not only by priority but also by target branch proposed by patch contributor who may only work on that branch release for a long time. I think this target/fix branch negotiation mechanism going on well and we shouldn't break it.
Thanks,
Junping
________________________________________
From: Andrew Wang <an...@cloudera.com>
Sent: Friday, January 08, 2016 7:43 PM
To: common-dev@hadoop.apache.org
Cc: mapreduce-dev@hadoop.apache.org; Vinod Kumar Vavilapalli; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.
Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.
Best,
Andrew
On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
wrote:
> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but not
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For “any fix in 2.6.3 to be there in all releases that get out after
>> 2.6.3 release date”
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility. I would prefer this rule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issues.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> ________________________________
>> From: Vinod Kumar Vavilapalli <vi...@apache.org>
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
>> >
>>
>> Two options here, depending on the importance of ‘causality' between
>> 2.6.x and 2.7.x lines.
>> - Ship 2.7.2 as we voted on here
>> - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect “any fix in 2.6.3 to be there in
>> all releases that get out after 2.6.3 release date (December 16th)”?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases that
>> got out after 2.6.3”), I’ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
>> jdu@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found something
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Andrew Wang <an...@cloudera.com>.
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.
Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.
Best,
Andrew
On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
wrote:
> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but not
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For “any fix in 2.6.3 to be there in all releases that get out after
>> 2.6.3 release date”
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility. I would prefer this rule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issues.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> ________________________________
>> From: Vinod Kumar Vavilapalli <vi...@apache.org>
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
>> >
>>
>> Two options here, depending on the importance of ‘causality' between
>> 2.6.x and 2.7.x lines.
>> - Ship 2.7.2 as we voted on here
>> - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect “any fix in 2.6.3 to be there in
>> all releases that get out after 2.6.3 release date (December 16th)”?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases that
>> got out after 2.6.3”), I’ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
>> jdu@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found something
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Andrew Wang <an...@cloudera.com>.
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.
Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.
Best,
Andrew
On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
wrote:
> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but not
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For “any fix in 2.6.3 to be there in all releases that get out after
>> 2.6.3 release date”
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility. I would prefer this rule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issues.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> ________________________________
>> From: Vinod Kumar Vavilapalli <vi...@apache.org>
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
>> >
>>
>> Two options here, depending on the importance of ‘causality' between
>> 2.6.x and 2.7.x lines.
>> - Ship 2.7.2 as we voted on here
>> - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect “any fix in 2.6.3 to be there in
>> all releases that get out after 2.6.3 release date (December 16th)”?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases that
>> got out after 2.6.3”), I’ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
>> jdu@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found something
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Andrew Wang <an...@cloudera.com>.
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.
Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.
Best,
Andrew
On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
wrote:
> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but not
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For “any fix in 2.6.3 to be there in all releases that get out after
>> 2.6.3 release date”
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility. I would prefer this rule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issues.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> ________________________________
>> From: Vinod Kumar Vavilapalli <vi...@apache.org>
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
>> >
>>
>> Two options here, depending on the importance of ‘causality' between
>> 2.6.x and 2.7.x lines.
>> - Ship 2.7.2 as we voted on here
>> - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect “any fix in 2.6.3 to be there in
>> all releases that get out after 2.6.3 release date (December 16th)”?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases that
>> got out after 2.6.3”), I’ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
>> jdu@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found something
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>
Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
Posted by Andrew Wang <an...@cloudera.com>.
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.
Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.
Best,
Andrew
On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <aj...@oss.nttdata.co.jp>
wrote:
> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but not
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For “any fix in 2.6.3 to be there in all releases that get out after
>> 2.6.3 release date”
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility. I would prefer this rule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issues.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> ________________________________
>> From: Vinod Kumar Vavilapalli <vi...@apache.org>
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
>> >
>>
>> Two options here, depending on the importance of ‘causality' between
>> 2.6.x and 2.7.x lines.
>> - Ship 2.7.2 as we voted on here
>> - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect “any fix in 2.6.3 to be there in
>> all releases that get out after 2.6.3 release date (December 16th)”?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vinodkv@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases that
>> got out after 2.6.3”), I’ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
>> jdu@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found something
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>