You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by Chris Trezzo <ct...@gmail.com> on 2016/09/09 20:24:14 UTC
Re: [Release thread] 2.6.5 release activities
Hi all,
I wanted to give an update on the Hadoop 2.6.5 release efforts.
Here is what has been done so far:
1. I have gone through all of the potential backports and recorded the
commit hashes for each of them from the branch that seems the most
appropriate (i.e. if there was a backport to 2.7.x then I used the hash
from the backport).
2. I verified if the cherry pick for each commit is clean. This was best
effort as some of the patches are in parts of the code that I am less
familiar with. This is recorded in the public spread sheet here:
https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
I am going to need help from committers to get these backports committed.
If there are any committers that have some spare cycles, especially if you
were involved with the initial commit for one of these issues, please look
at the spreadsheet and volunteer to backport one of the issues.
As always, please let me know if you have any questions or feel that I have
missed something.
Thank you!
Chris Trezzo
On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <aw@effectivemachines.com
> wrote:
>
> > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
> >
> > In this community, we are so aggressive to drop Java 7 support in 3.0.x
> release. Here, why we are so conservative to keep releasing new bits to
> support Java 6?
>
> I don't view a group of people putting bug fixes into a micro
> release as particularly conservative. If a group within the community
> wasn't interested in doing it, 2.6.5 wouldn't be happening.
>
> But let's put the releases into context, because I think it tells
> a more interesting story.
>
> * hadoop 2.6.x = EOLed JREs (6,7)
> * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
> * hadoop 3.x = JRE 8
> * hadoop 4.x = JRE 9
>
> There are groups of people still using JDK6 and they want bug
> fixes in a maintenance release. Boom, there's 2.6.x.
>
> Hadoop 3.x has been pushed off for years for "reasons". So we
> still have releases coming off of branch-2. If 2.7 had been released as
> 3.x, this chart would look less weird. But it wasn't thus 2.x has this
> weird wart in the middle of that supports JDK7 and JDK8. Given the public
> policy and roadmaps of at least one major vendor at the time of this
> writing, we should expect to see JDK7 support for at least the next two
> years after 3.x appears. Bang, there's 2.x, where x is some large number.
>
> Then there is the future. People using JRE 8 want to use newer
> dependencies. A reasonable request. Some of these dependency updates won't
> work with JRE 7. We can't do that in hadoop 2.x in any sort of compatible
> way without breaking the universe. (Tons of JIRAs on this point.) This
> means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
> Kapow, there's 3.x
>
> The log4j community has stated that v1 won't work with JDK9. In
> turn, this means we'll need to upgrade to v2 at some point. Upgrading to
> v2 will break the log4j properties file (and maybe other things?). Another
> incompatible change and it likely won't appear until Apache Hadoop v4
> unless someone takes the initiative to fix it before v3 hits store
> shelves. This makes JDK9 the likely target for Apache Hadoop v4.
>
> Having major release cadences tied to JRE updates isn't
> necessarily a bad thing and definitely forces the community to a) actually
> stop beating around the bush on majors and b) actually makes it relatively
> easy to determine what the schedule looks like to some degree.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
>
Re: [Release thread] 2.6.5 release activities
Posted by Chris Trezzo <ct...@gmail.com>.
We have now cut branch-2.6.5.
On Wed, Sep 14, 2016 at 4:38 PM, Sangjin Lee <sj...@apache.org> wrote:
> We ported 16 issues to branch-2.6. We will go ahead and start the release
> process, including cutting the release branch. If you have any critical
> change that should be made part of 2.6.5, please reach out to us and commit
> the changes. Thanks!
>
> Sangjin
>
> On Mon, Sep 12, 2016 at 3:24 PM, Sangjin Lee <sj...@apache.org> wrote:
>
>> Thanks Chris!
>>
>> I'll help Chris to get those JIRAs marked in his spreadsheet committed.
>> We'll cut the release branch shortly after that. If you have any critical
>> change that should be made part of 2.6.5 (CVE patches included), please
>> reach out to us and commit the changes. If all things go well, we'd like to
>> cut the branch in a few days.
>>
>> Thanks,
>> Sangjin
>>
>> On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>>>
>>> Here is what has been done so far:
>>>
>>> 1. I have gone through all of the potential backports and recorded the
>>> commit hashes for each of them from the branch that seems the most
>>> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
>>> from the backport).
>>>
>>> 2. I verified if the cherry pick for each commit is clean. This was best
>>> effort as some of the patches are in parts of the code that I am less
>>> familiar with. This is recorded in the public spread sheet here:
>>> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
>>> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>>>
>>> I am going to need help from committers to get these backports committed.
>>> If there are any committers that have some spare cycles, especially if
>>> you
>>> were involved with the initial commit for one of these issues, please
>>> look
>>> at the spreadsheet and volunteer to backport one of the issues.
>>>
>>> As always, please let me know if you have any questions or feel that I
>>> have
>>> missed something.
>>>
>>> Thank you!
>>> Chris Trezzo
>>>
>>> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
>>> aw@effectivemachines.com
>>> > wrote:
>>>
>>> >
>>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
>>> > >
>>> > > In this community, we are so aggressive to drop Java 7 support in
>>> 3.0.x
>>> > release. Here, why we are so conservative to keep releasing new bits to
>>> > support Java 6?
>>> >
>>> > I don't view a group of people putting bug fixes into a micro
>>> > release as particularly conservative. If a group within the community
>>> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
>>> >
>>> > But let's put the releases into context, because I think it
>>> tells
>>> > a more interesting story.
>>> >
>>> > * hadoop 2.6.x = EOLed JREs (6,7)
>>> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
>>> > * hadoop 3.x = JRE 8
>>> > * hadoop 4.x = JRE 9
>>> >
>>> > There are groups of people still using JDK6 and they want bug
>>> > fixes in a maintenance release. Boom, there's 2.6.x.
>>> >
>>> > Hadoop 3.x has been pushed off for years for "reasons". So we
>>> > still have releases coming off of branch-2. If 2.7 had been released
>>> as
>>> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
>>> > weird wart in the middle of that supports JDK7 and JDK8. Given the
>>> public
>>> > policy and roadmaps of at least one major vendor at the time of this
>>> > writing, we should expect to see JDK7 support for at least the next two
>>> > years after 3.x appears. Bang, there's 2.x, where x is some large
>>> number.
>>> >
>>> > Then there is the future. People using JRE 8 want to use newer
>>> > dependencies. A reasonable request. Some of these dependency updates
>>> won't
>>> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
>>> compatible
>>> > way without breaking the universe. (Tons of JIRAs on this point.) This
>>> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
>>> > Kapow, there's 3.x
>>> >
>>> > The log4j community has stated that v1 won't work with JDK9. In
>>> > turn, this means we'll need to upgrade to v2 at some point. Upgrading
>>> to
>>> > v2 will break the log4j properties file (and maybe other things?).
>>> Another
>>> > incompatible change and it likely won't appear until Apache Hadoop v4
>>> > unless someone takes the initiative to fix it before v3 hits store
>>> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
>>> >
>>> > Having major release cadences tied to JRE updates isn't
>>> > necessarily a bad thing and definitely forces the community to a)
>>> actually
>>> > stop beating around the bush on majors and b) actually makes it
>>> relatively
>>> > easy to determine what the schedule looks like to some degree.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>>> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>> >
>>> >
>>>
>>
>>
>
Re: [Release thread] 2.6.5 release activities
Posted by Chris Trezzo <ct...@gmail.com>.
We have now cut branch-2.6.5.
On Wed, Sep 14, 2016 at 4:38 PM, Sangjin Lee <sj...@apache.org> wrote:
> We ported 16 issues to branch-2.6. We will go ahead and start the release
> process, including cutting the release branch. If you have any critical
> change that should be made part of 2.6.5, please reach out to us and commit
> the changes. Thanks!
>
> Sangjin
>
> On Mon, Sep 12, 2016 at 3:24 PM, Sangjin Lee <sj...@apache.org> wrote:
>
>> Thanks Chris!
>>
>> I'll help Chris to get those JIRAs marked in his spreadsheet committed.
>> We'll cut the release branch shortly after that. If you have any critical
>> change that should be made part of 2.6.5 (CVE patches included), please
>> reach out to us and commit the changes. If all things go well, we'd like to
>> cut the branch in a few days.
>>
>> Thanks,
>> Sangjin
>>
>> On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>>>
>>> Here is what has been done so far:
>>>
>>> 1. I have gone through all of the potential backports and recorded the
>>> commit hashes for each of them from the branch that seems the most
>>> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
>>> from the backport).
>>>
>>> 2. I verified if the cherry pick for each commit is clean. This was best
>>> effort as some of the patches are in parts of the code that I am less
>>> familiar with. This is recorded in the public spread sheet here:
>>> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
>>> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>>>
>>> I am going to need help from committers to get these backports committed.
>>> If there are any committers that have some spare cycles, especially if
>>> you
>>> were involved with the initial commit for one of these issues, please
>>> look
>>> at the spreadsheet and volunteer to backport one of the issues.
>>>
>>> As always, please let me know if you have any questions or feel that I
>>> have
>>> missed something.
>>>
>>> Thank you!
>>> Chris Trezzo
>>>
>>> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
>>> aw@effectivemachines.com
>>> > wrote:
>>>
>>> >
>>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
>>> > >
>>> > > In this community, we are so aggressive to drop Java 7 support in
>>> 3.0.x
>>> > release. Here, why we are so conservative to keep releasing new bits to
>>> > support Java 6?
>>> >
>>> > I don't view a group of people putting bug fixes into a micro
>>> > release as particularly conservative. If a group within the community
>>> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
>>> >
>>> > But let's put the releases into context, because I think it
>>> tells
>>> > a more interesting story.
>>> >
>>> > * hadoop 2.6.x = EOLed JREs (6,7)
>>> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
>>> > * hadoop 3.x = JRE 8
>>> > * hadoop 4.x = JRE 9
>>> >
>>> > There are groups of people still using JDK6 and they want bug
>>> > fixes in a maintenance release. Boom, there's 2.6.x.
>>> >
>>> > Hadoop 3.x has been pushed off for years for "reasons". So we
>>> > still have releases coming off of branch-2. If 2.7 had been released
>>> as
>>> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
>>> > weird wart in the middle of that supports JDK7 and JDK8. Given the
>>> public
>>> > policy and roadmaps of at least one major vendor at the time of this
>>> > writing, we should expect to see JDK7 support for at least the next two
>>> > years after 3.x appears. Bang, there's 2.x, where x is some large
>>> number.
>>> >
>>> > Then there is the future. People using JRE 8 want to use newer
>>> > dependencies. A reasonable request. Some of these dependency updates
>>> won't
>>> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
>>> compatible
>>> > way without breaking the universe. (Tons of JIRAs on this point.) This
>>> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
>>> > Kapow, there's 3.x
>>> >
>>> > The log4j community has stated that v1 won't work with JDK9. In
>>> > turn, this means we'll need to upgrade to v2 at some point. Upgrading
>>> to
>>> > v2 will break the log4j properties file (and maybe other things?).
>>> Another
>>> > incompatible change and it likely won't appear until Apache Hadoop v4
>>> > unless someone takes the initiative to fix it before v3 hits store
>>> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
>>> >
>>> > Having major release cadences tied to JRE updates isn't
>>> > necessarily a bad thing and definitely forces the community to a)
>>> actually
>>> > stop beating around the bush on majors and b) actually makes it
>>> relatively
>>> > easy to determine what the schedule looks like to some degree.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>>> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>> >
>>> >
>>>
>>
>>
>
Re: [Release thread] 2.6.5 release activities
Posted by Chris Trezzo <ct...@gmail.com>.
We have now cut branch-2.6.5.
On Wed, Sep 14, 2016 at 4:38 PM, Sangjin Lee <sj...@apache.org> wrote:
> We ported 16 issues to branch-2.6. We will go ahead and start the release
> process, including cutting the release branch. If you have any critical
> change that should be made part of 2.6.5, please reach out to us and commit
> the changes. Thanks!
>
> Sangjin
>
> On Mon, Sep 12, 2016 at 3:24 PM, Sangjin Lee <sj...@apache.org> wrote:
>
>> Thanks Chris!
>>
>> I'll help Chris to get those JIRAs marked in his spreadsheet committed.
>> We'll cut the release branch shortly after that. If you have any critical
>> change that should be made part of 2.6.5 (CVE patches included), please
>> reach out to us and commit the changes. If all things go well, we'd like to
>> cut the branch in a few days.
>>
>> Thanks,
>> Sangjin
>>
>> On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>>>
>>> Here is what has been done so far:
>>>
>>> 1. I have gone through all of the potential backports and recorded the
>>> commit hashes for each of them from the branch that seems the most
>>> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
>>> from the backport).
>>>
>>> 2. I verified if the cherry pick for each commit is clean. This was best
>>> effort as some of the patches are in parts of the code that I am less
>>> familiar with. This is recorded in the public spread sheet here:
>>> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
>>> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>>>
>>> I am going to need help from committers to get these backports committed.
>>> If there are any committers that have some spare cycles, especially if
>>> you
>>> were involved with the initial commit for one of these issues, please
>>> look
>>> at the spreadsheet and volunteer to backport one of the issues.
>>>
>>> As always, please let me know if you have any questions or feel that I
>>> have
>>> missed something.
>>>
>>> Thank you!
>>> Chris Trezzo
>>>
>>> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
>>> aw@effectivemachines.com
>>> > wrote:
>>>
>>> >
>>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
>>> > >
>>> > > In this community, we are so aggressive to drop Java 7 support in
>>> 3.0.x
>>> > release. Here, why we are so conservative to keep releasing new bits to
>>> > support Java 6?
>>> >
>>> > I don't view a group of people putting bug fixes into a micro
>>> > release as particularly conservative. If a group within the community
>>> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
>>> >
>>> > But let's put the releases into context, because I think it
>>> tells
>>> > a more interesting story.
>>> >
>>> > * hadoop 2.6.x = EOLed JREs (6,7)
>>> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
>>> > * hadoop 3.x = JRE 8
>>> > * hadoop 4.x = JRE 9
>>> >
>>> > There are groups of people still using JDK6 and they want bug
>>> > fixes in a maintenance release. Boom, there's 2.6.x.
>>> >
>>> > Hadoop 3.x has been pushed off for years for "reasons". So we
>>> > still have releases coming off of branch-2. If 2.7 had been released
>>> as
>>> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
>>> > weird wart in the middle of that supports JDK7 and JDK8. Given the
>>> public
>>> > policy and roadmaps of at least one major vendor at the time of this
>>> > writing, we should expect to see JDK7 support for at least the next two
>>> > years after 3.x appears. Bang, there's 2.x, where x is some large
>>> number.
>>> >
>>> > Then there is the future. People using JRE 8 want to use newer
>>> > dependencies. A reasonable request. Some of these dependency updates
>>> won't
>>> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
>>> compatible
>>> > way without breaking the universe. (Tons of JIRAs on this point.) This
>>> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
>>> > Kapow, there's 3.x
>>> >
>>> > The log4j community has stated that v1 won't work with JDK9. In
>>> > turn, this means we'll need to upgrade to v2 at some point. Upgrading
>>> to
>>> > v2 will break the log4j properties file (and maybe other things?).
>>> Another
>>> > incompatible change and it likely won't appear until Apache Hadoop v4
>>> > unless someone takes the initiative to fix it before v3 hits store
>>> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
>>> >
>>> > Having major release cadences tied to JRE updates isn't
>>> > necessarily a bad thing and definitely forces the community to a)
>>> actually
>>> > stop beating around the bush on majors and b) actually makes it
>>> relatively
>>> > easy to determine what the schedule looks like to some degree.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>>> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>> >
>>> >
>>>
>>
>>
>
Re: [Release thread] 2.6.5 release activities
Posted by Chris Trezzo <ct...@gmail.com>.
We have now cut branch-2.6.5.
On Wed, Sep 14, 2016 at 4:38 PM, Sangjin Lee <sj...@apache.org> wrote:
> We ported 16 issues to branch-2.6. We will go ahead and start the release
> process, including cutting the release branch. If you have any critical
> change that should be made part of 2.6.5, please reach out to us and commit
> the changes. Thanks!
>
> Sangjin
>
> On Mon, Sep 12, 2016 at 3:24 PM, Sangjin Lee <sj...@apache.org> wrote:
>
>> Thanks Chris!
>>
>> I'll help Chris to get those JIRAs marked in his spreadsheet committed.
>> We'll cut the release branch shortly after that. If you have any critical
>> change that should be made part of 2.6.5 (CVE patches included), please
>> reach out to us and commit the changes. If all things go well, we'd like to
>> cut the branch in a few days.
>>
>> Thanks,
>> Sangjin
>>
>> On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>>>
>>> Here is what has been done so far:
>>>
>>> 1. I have gone through all of the potential backports and recorded the
>>> commit hashes for each of them from the branch that seems the most
>>> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
>>> from the backport).
>>>
>>> 2. I verified if the cherry pick for each commit is clean. This was best
>>> effort as some of the patches are in parts of the code that I am less
>>> familiar with. This is recorded in the public spread sheet here:
>>> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
>>> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>>>
>>> I am going to need help from committers to get these backports committed.
>>> If there are any committers that have some spare cycles, especially if
>>> you
>>> were involved with the initial commit for one of these issues, please
>>> look
>>> at the spreadsheet and volunteer to backport one of the issues.
>>>
>>> As always, please let me know if you have any questions or feel that I
>>> have
>>> missed something.
>>>
>>> Thank you!
>>> Chris Trezzo
>>>
>>> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
>>> aw@effectivemachines.com
>>> > wrote:
>>>
>>> >
>>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
>>> > >
>>> > > In this community, we are so aggressive to drop Java 7 support in
>>> 3.0.x
>>> > release. Here, why we are so conservative to keep releasing new bits to
>>> > support Java 6?
>>> >
>>> > I don't view a group of people putting bug fixes into a micro
>>> > release as particularly conservative. If a group within the community
>>> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
>>> >
>>> > But let's put the releases into context, because I think it
>>> tells
>>> > a more interesting story.
>>> >
>>> > * hadoop 2.6.x = EOLed JREs (6,7)
>>> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
>>> > * hadoop 3.x = JRE 8
>>> > * hadoop 4.x = JRE 9
>>> >
>>> > There are groups of people still using JDK6 and they want bug
>>> > fixes in a maintenance release. Boom, there's 2.6.x.
>>> >
>>> > Hadoop 3.x has been pushed off for years for "reasons". So we
>>> > still have releases coming off of branch-2. If 2.7 had been released
>>> as
>>> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
>>> > weird wart in the middle of that supports JDK7 and JDK8. Given the
>>> public
>>> > policy and roadmaps of at least one major vendor at the time of this
>>> > writing, we should expect to see JDK7 support for at least the next two
>>> > years after 3.x appears. Bang, there's 2.x, where x is some large
>>> number.
>>> >
>>> > Then there is the future. People using JRE 8 want to use newer
>>> > dependencies. A reasonable request. Some of these dependency updates
>>> won't
>>> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
>>> compatible
>>> > way without breaking the universe. (Tons of JIRAs on this point.) This
>>> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
>>> > Kapow, there's 3.x
>>> >
>>> > The log4j community has stated that v1 won't work with JDK9. In
>>> > turn, this means we'll need to upgrade to v2 at some point. Upgrading
>>> to
>>> > v2 will break the log4j properties file (and maybe other things?).
>>> Another
>>> > incompatible change and it likely won't appear until Apache Hadoop v4
>>> > unless someone takes the initiative to fix it before v3 hits store
>>> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
>>> >
>>> > Having major release cadences tied to JRE updates isn't
>>> > necessarily a bad thing and definitely forces the community to a)
>>> actually
>>> > stop beating around the bush on majors and b) actually makes it
>>> relatively
>>> > easy to determine what the schedule looks like to some degree.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>>> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>> >
>>> >
>>>
>>
>>
>
Re: [Release thread] 2.6.5 release activities
Posted by Sangjin Lee <sj...@apache.org>.
We ported 16 issues to branch-2.6. We will go ahead and start the release
process, including cutting the release branch. If you have any critical
change that should be made part of 2.6.5, please reach out to us and commit
the changes. Thanks!
Sangjin
On Mon, Sep 12, 2016 at 3:24 PM, Sangjin Lee <sj...@apache.org> wrote:
> Thanks Chris!
>
> I'll help Chris to get those JIRAs marked in his spreadsheet committed.
> We'll cut the release branch shortly after that. If you have any critical
> change that should be made part of 2.6.5 (CVE patches included), please
> reach out to us and commit the changes. If all things go well, we'd like to
> cut the branch in a few days.
>
> Thanks,
> Sangjin
>
> On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
>
>> Hi all,
>>
>> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>>
>> Here is what has been done so far:
>>
>> 1. I have gone through all of the potential backports and recorded the
>> commit hashes for each of them from the branch that seems the most
>> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
>> from the backport).
>>
>> 2. I verified if the cherry pick for each commit is clean. This was best
>> effort as some of the patches are in parts of the code that I am less
>> familiar with. This is recorded in the public spread sheet here:
>> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
>> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>>
>> I am going to need help from committers to get these backports committed.
>> If there are any committers that have some spare cycles, especially if you
>> were involved with the initial commit for one of these issues, please look
>> at the spreadsheet and volunteer to backport one of the issues.
>>
>> As always, please let me know if you have any questions or feel that I
>> have
>> missed something.
>>
>> Thank you!
>> Chris Trezzo
>>
>> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
>> aw@effectivemachines.com
>> > wrote:
>>
>> >
>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
>> > >
>> > > In this community, we are so aggressive to drop Java 7 support in
>> 3.0.x
>> > release. Here, why we are so conservative to keep releasing new bits to
>> > support Java 6?
>> >
>> > I don't view a group of people putting bug fixes into a micro
>> > release as particularly conservative. If a group within the community
>> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
>> >
>> > But let's put the releases into context, because I think it
>> tells
>> > a more interesting story.
>> >
>> > * hadoop 2.6.x = EOLed JREs (6,7)
>> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
>> > * hadoop 3.x = JRE 8
>> > * hadoop 4.x = JRE 9
>> >
>> > There are groups of people still using JDK6 and they want bug
>> > fixes in a maintenance release. Boom, there's 2.6.x.
>> >
>> > Hadoop 3.x has been pushed off for years for "reasons". So we
>> > still have releases coming off of branch-2. If 2.7 had been released as
>> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
>> > weird wart in the middle of that supports JDK7 and JDK8. Given the
>> public
>> > policy and roadmaps of at least one major vendor at the time of this
>> > writing, we should expect to see JDK7 support for at least the next two
>> > years after 3.x appears. Bang, there's 2.x, where x is some large
>> number.
>> >
>> > Then there is the future. People using JRE 8 want to use newer
>> > dependencies. A reasonable request. Some of these dependency updates
>> won't
>> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
>> compatible
>> > way without breaking the universe. (Tons of JIRAs on this point.) This
>> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
>> > Kapow, there's 3.x
>> >
>> > The log4j community has stated that v1 won't work with JDK9. In
>> > turn, this means we'll need to upgrade to v2 at some point. Upgrading
>> to
>> > v2 will break the log4j properties file (and maybe other things?).
>> Another
>> > incompatible change and it likely won't appear until Apache Hadoop v4
>> > unless someone takes the initiative to fix it before v3 hits store
>> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
>> >
>> > Having major release cadences tied to JRE updates isn't
>> > necessarily a bad thing and definitely forces the community to a)
>> actually
>> > stop beating around the bush on majors and b) actually makes it
>> relatively
>> > easy to determine what the schedule looks like to some degree.
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> >
>> >
>>
>
>
Re: [Release thread] 2.6.5 release activities
Posted by Sangjin Lee <sj...@apache.org>.
We ported 16 issues to branch-2.6. We will go ahead and start the release
process, including cutting the release branch. If you have any critical
change that should be made part of 2.6.5, please reach out to us and commit
the changes. Thanks!
Sangjin
On Mon, Sep 12, 2016 at 3:24 PM, Sangjin Lee <sj...@apache.org> wrote:
> Thanks Chris!
>
> I'll help Chris to get those JIRAs marked in his spreadsheet committed.
> We'll cut the release branch shortly after that. If you have any critical
> change that should be made part of 2.6.5 (CVE patches included), please
> reach out to us and commit the changes. If all things go well, we'd like to
> cut the branch in a few days.
>
> Thanks,
> Sangjin
>
> On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
>
>> Hi all,
>>
>> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>>
>> Here is what has been done so far:
>>
>> 1. I have gone through all of the potential backports and recorded the
>> commit hashes for each of them from the branch that seems the most
>> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
>> from the backport).
>>
>> 2. I verified if the cherry pick for each commit is clean. This was best
>> effort as some of the patches are in parts of the code that I am less
>> familiar with. This is recorded in the public spread sheet here:
>> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
>> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>>
>> I am going to need help from committers to get these backports committed.
>> If there are any committers that have some spare cycles, especially if you
>> were involved with the initial commit for one of these issues, please look
>> at the spreadsheet and volunteer to backport one of the issues.
>>
>> As always, please let me know if you have any questions or feel that I
>> have
>> missed something.
>>
>> Thank you!
>> Chris Trezzo
>>
>> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
>> aw@effectivemachines.com
>> > wrote:
>>
>> >
>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
>> > >
>> > > In this community, we are so aggressive to drop Java 7 support in
>> 3.0.x
>> > release. Here, why we are so conservative to keep releasing new bits to
>> > support Java 6?
>> >
>> > I don't view a group of people putting bug fixes into a micro
>> > release as particularly conservative. If a group within the community
>> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
>> >
>> > But let's put the releases into context, because I think it
>> tells
>> > a more interesting story.
>> >
>> > * hadoop 2.6.x = EOLed JREs (6,7)
>> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
>> > * hadoop 3.x = JRE 8
>> > * hadoop 4.x = JRE 9
>> >
>> > There are groups of people still using JDK6 and they want bug
>> > fixes in a maintenance release. Boom, there's 2.6.x.
>> >
>> > Hadoop 3.x has been pushed off for years for "reasons". So we
>> > still have releases coming off of branch-2. If 2.7 had been released as
>> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
>> > weird wart in the middle of that supports JDK7 and JDK8. Given the
>> public
>> > policy and roadmaps of at least one major vendor at the time of this
>> > writing, we should expect to see JDK7 support for at least the next two
>> > years after 3.x appears. Bang, there's 2.x, where x is some large
>> number.
>> >
>> > Then there is the future. People using JRE 8 want to use newer
>> > dependencies. A reasonable request. Some of these dependency updates
>> won't
>> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
>> compatible
>> > way without breaking the universe. (Tons of JIRAs on this point.) This
>> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
>> > Kapow, there's 3.x
>> >
>> > The log4j community has stated that v1 won't work with JDK9. In
>> > turn, this means we'll need to upgrade to v2 at some point. Upgrading
>> to
>> > v2 will break the log4j properties file (and maybe other things?).
>> Another
>> > incompatible change and it likely won't appear until Apache Hadoop v4
>> > unless someone takes the initiative to fix it before v3 hits store
>> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
>> >
>> > Having major release cadences tied to JRE updates isn't
>> > necessarily a bad thing and definitely forces the community to a)
>> actually
>> > stop beating around the bush on majors and b) actually makes it
>> relatively
>> > easy to determine what the schedule looks like to some degree.
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> >
>> >
>>
>
>
Re: [Release thread] 2.6.5 release activities
Posted by Sangjin Lee <sj...@apache.org>.
We ported 16 issues to branch-2.6. We will go ahead and start the release
process, including cutting the release branch. If you have any critical
change that should be made part of 2.6.5, please reach out to us and commit
the changes. Thanks!
Sangjin
On Mon, Sep 12, 2016 at 3:24 PM, Sangjin Lee <sj...@apache.org> wrote:
> Thanks Chris!
>
> I'll help Chris to get those JIRAs marked in his spreadsheet committed.
> We'll cut the release branch shortly after that. If you have any critical
> change that should be made part of 2.6.5 (CVE patches included), please
> reach out to us and commit the changes. If all things go well, we'd like to
> cut the branch in a few days.
>
> Thanks,
> Sangjin
>
> On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
>
>> Hi all,
>>
>> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>>
>> Here is what has been done so far:
>>
>> 1. I have gone through all of the potential backports and recorded the
>> commit hashes for each of them from the branch that seems the most
>> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
>> from the backport).
>>
>> 2. I verified if the cherry pick for each commit is clean. This was best
>> effort as some of the patches are in parts of the code that I am less
>> familiar with. This is recorded in the public spread sheet here:
>> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
>> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>>
>> I am going to need help from committers to get these backports committed.
>> If there are any committers that have some spare cycles, especially if you
>> were involved with the initial commit for one of these issues, please look
>> at the spreadsheet and volunteer to backport one of the issues.
>>
>> As always, please let me know if you have any questions or feel that I
>> have
>> missed something.
>>
>> Thank you!
>> Chris Trezzo
>>
>> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
>> aw@effectivemachines.com
>> > wrote:
>>
>> >
>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
>> > >
>> > > In this community, we are so aggressive to drop Java 7 support in
>> 3.0.x
>> > release. Here, why we are so conservative to keep releasing new bits to
>> > support Java 6?
>> >
>> > I don't view a group of people putting bug fixes into a micro
>> > release as particularly conservative. If a group within the community
>> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
>> >
>> > But let's put the releases into context, because I think it
>> tells
>> > a more interesting story.
>> >
>> > * hadoop 2.6.x = EOLed JREs (6,7)
>> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
>> > * hadoop 3.x = JRE 8
>> > * hadoop 4.x = JRE 9
>> >
>> > There are groups of people still using JDK6 and they want bug
>> > fixes in a maintenance release. Boom, there's 2.6.x.
>> >
>> > Hadoop 3.x has been pushed off for years for "reasons". So we
>> > still have releases coming off of branch-2. If 2.7 had been released as
>> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
>> > weird wart in the middle of that supports JDK7 and JDK8. Given the
>> public
>> > policy and roadmaps of at least one major vendor at the time of this
>> > writing, we should expect to see JDK7 support for at least the next two
>> > years after 3.x appears. Bang, there's 2.x, where x is some large
>> number.
>> >
>> > Then there is the future. People using JRE 8 want to use newer
>> > dependencies. A reasonable request. Some of these dependency updates
>> won't
>> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
>> compatible
>> > way without breaking the universe. (Tons of JIRAs on this point.) This
>> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
>> > Kapow, there's 3.x
>> >
>> > The log4j community has stated that v1 won't work with JDK9. In
>> > turn, this means we'll need to upgrade to v2 at some point. Upgrading
>> to
>> > v2 will break the log4j properties file (and maybe other things?).
>> Another
>> > incompatible change and it likely won't appear until Apache Hadoop v4
>> > unless someone takes the initiative to fix it before v3 hits store
>> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
>> >
>> > Having major release cadences tied to JRE updates isn't
>> > necessarily a bad thing and definitely forces the community to a)
>> actually
>> > stop beating around the bush on majors and b) actually makes it
>> relatively
>> > easy to determine what the schedule looks like to some degree.
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> >
>> >
>>
>
>
Re: [Release thread] 2.6.5 release activities
Posted by Sangjin Lee <sj...@apache.org>.
We ported 16 issues to branch-2.6. We will go ahead and start the release
process, including cutting the release branch. If you have any critical
change that should be made part of 2.6.5, please reach out to us and commit
the changes. Thanks!
Sangjin
On Mon, Sep 12, 2016 at 3:24 PM, Sangjin Lee <sj...@apache.org> wrote:
> Thanks Chris!
>
> I'll help Chris to get those JIRAs marked in his spreadsheet committed.
> We'll cut the release branch shortly after that. If you have any critical
> change that should be made part of 2.6.5 (CVE patches included), please
> reach out to us and commit the changes. If all things go well, we'd like to
> cut the branch in a few days.
>
> Thanks,
> Sangjin
>
> On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
>
>> Hi all,
>>
>> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>>
>> Here is what has been done so far:
>>
>> 1. I have gone through all of the potential backports and recorded the
>> commit hashes for each of them from the branch that seems the most
>> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
>> from the backport).
>>
>> 2. I verified if the cherry pick for each commit is clean. This was best
>> effort as some of the patches are in parts of the code that I am less
>> familiar with. This is recorded in the public spread sheet here:
>> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
>> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>>
>> I am going to need help from committers to get these backports committed.
>> If there are any committers that have some spare cycles, especially if you
>> were involved with the initial commit for one of these issues, please look
>> at the spreadsheet and volunteer to backport one of the issues.
>>
>> As always, please let me know if you have any questions or feel that I
>> have
>> missed something.
>>
>> Thank you!
>> Chris Trezzo
>>
>> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
>> aw@effectivemachines.com
>> > wrote:
>>
>> >
>> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
>> > >
>> > > In this community, we are so aggressive to drop Java 7 support in
>> 3.0.x
>> > release. Here, why we are so conservative to keep releasing new bits to
>> > support Java 6?
>> >
>> > I don't view a group of people putting bug fixes into a micro
>> > release as particularly conservative. If a group within the community
>> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
>> >
>> > But let's put the releases into context, because I think it
>> tells
>> > a more interesting story.
>> >
>> > * hadoop 2.6.x = EOLed JREs (6,7)
>> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
>> > * hadoop 3.x = JRE 8
>> > * hadoop 4.x = JRE 9
>> >
>> > There are groups of people still using JDK6 and they want bug
>> > fixes in a maintenance release. Boom, there's 2.6.x.
>> >
>> > Hadoop 3.x has been pushed off for years for "reasons". So we
>> > still have releases coming off of branch-2. If 2.7 had been released as
>> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
>> > weird wart in the middle of that supports JDK7 and JDK8. Given the
>> public
>> > policy and roadmaps of at least one major vendor at the time of this
>> > writing, we should expect to see JDK7 support for at least the next two
>> > years after 3.x appears. Bang, there's 2.x, where x is some large
>> number.
>> >
>> > Then there is the future. People using JRE 8 want to use newer
>> > dependencies. A reasonable request. Some of these dependency updates
>> won't
>> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
>> compatible
>> > way without breaking the universe. (Tons of JIRAs on this point.) This
>> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
>> > Kapow, there's 3.x
>> >
>> > The log4j community has stated that v1 won't work with JDK9. In
>> > turn, this means we'll need to upgrade to v2 at some point. Upgrading
>> to
>> > v2 will break the log4j properties file (and maybe other things?).
>> Another
>> > incompatible change and it likely won't appear until Apache Hadoop v4
>> > unless someone takes the initiative to fix it before v3 hits store
>> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
>> >
>> > Having major release cadences tied to JRE updates isn't
>> > necessarily a bad thing and definitely forces the community to a)
>> actually
>> > stop beating around the bush on majors and b) actually makes it
>> relatively
>> > easy to determine what the schedule looks like to some degree.
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> >
>> >
>>
>
>
Re: [Release thread] 2.6.5 release activities
Posted by Sangjin Lee <sj...@apache.org>.
Thanks Chris!
I'll help Chris to get those JIRAs marked in his spreadsheet committed.
We'll cut the release branch shortly after that. If you have any critical
change that should be made part of 2.6.5 (CVE patches included), please
reach out to us and commit the changes. If all things go well, we'd like to
cut the branch in a few days.
Thanks,
Sangjin
On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
> Hi all,
>
> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>
> Here is what has been done so far:
>
> 1. I have gone through all of the potential backports and recorded the
> commit hashes for each of them from the branch that seems the most
> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
> from the backport).
>
> 2. I verified if the cherry pick for each commit is clean. This was best
> effort as some of the patches are in parts of the code that I am less
> familiar with. This is recorded in the public spread sheet here:
> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>
> I am going to need help from committers to get these backports committed.
> If there are any committers that have some spare cycles, especially if you
> were involved with the initial commit for one of these issues, please look
> at the spreadsheet and volunteer to backport one of the issues.
>
> As always, please let me know if you have any questions or feel that I have
> missed something.
>
> Thank you!
> Chris Trezzo
>
> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
> aw@effectivemachines.com
> > wrote:
>
> >
> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
> > >
> > > In this community, we are so aggressive to drop Java 7 support in
> 3.0.x
> > release. Here, why we are so conservative to keep releasing new bits to
> > support Java 6?
> >
> > I don't view a group of people putting bug fixes into a micro
> > release as particularly conservative. If a group within the community
> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
> >
> > But let's put the releases into context, because I think it tells
> > a more interesting story.
> >
> > * hadoop 2.6.x = EOLed JREs (6,7)
> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
> > * hadoop 3.x = JRE 8
> > * hadoop 4.x = JRE 9
> >
> > There are groups of people still using JDK6 and they want bug
> > fixes in a maintenance release. Boom, there's 2.6.x.
> >
> > Hadoop 3.x has been pushed off for years for "reasons". So we
> > still have releases coming off of branch-2. If 2.7 had been released as
> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
> > weird wart in the middle of that supports JDK7 and JDK8. Given the
> public
> > policy and roadmaps of at least one major vendor at the time of this
> > writing, we should expect to see JDK7 support for at least the next two
> > years after 3.x appears. Bang, there's 2.x, where x is some large number.
> >
> > Then there is the future. People using JRE 8 want to use newer
> > dependencies. A reasonable request. Some of these dependency updates
> won't
> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
> compatible
> > way without breaking the universe. (Tons of JIRAs on this point.) This
> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
> > Kapow, there's 3.x
> >
> > The log4j community has stated that v1 won't work with JDK9. In
> > turn, this means we'll need to upgrade to v2 at some point. Upgrading to
> > v2 will break the log4j properties file (and maybe other things?).
> Another
> > incompatible change and it likely won't appear until Apache Hadoop v4
> > unless someone takes the initiative to fix it before v3 hits store
> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
> >
> > Having major release cadences tied to JRE updates isn't
> > necessarily a bad thing and definitely forces the community to a)
> actually
> > stop beating around the bush on majors and b) actually makes it
> relatively
> > easy to determine what the schedule looks like to some degree.
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >
> >
>
Re: [Release thread] 2.6.5 release activities
Posted by Sangjin Lee <sj...@apache.org>.
Thanks Chris!
I'll help Chris to get those JIRAs marked in his spreadsheet committed.
We'll cut the release branch shortly after that. If you have any critical
change that should be made part of 2.6.5 (CVE patches included), please
reach out to us and commit the changes. If all things go well, we'd like to
cut the branch in a few days.
Thanks,
Sangjin
On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
> Hi all,
>
> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>
> Here is what has been done so far:
>
> 1. I have gone through all of the potential backports and recorded the
> commit hashes for each of them from the branch that seems the most
> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
> from the backport).
>
> 2. I verified if the cherry pick for each commit is clean. This was best
> effort as some of the patches are in parts of the code that I am less
> familiar with. This is recorded in the public spread sheet here:
> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>
> I am going to need help from committers to get these backports committed.
> If there are any committers that have some spare cycles, especially if you
> were involved with the initial commit for one of these issues, please look
> at the spreadsheet and volunteer to backport one of the issues.
>
> As always, please let me know if you have any questions or feel that I have
> missed something.
>
> Thank you!
> Chris Trezzo
>
> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
> aw@effectivemachines.com
> > wrote:
>
> >
> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
> > >
> > > In this community, we are so aggressive to drop Java 7 support in
> 3.0.x
> > release. Here, why we are so conservative to keep releasing new bits to
> > support Java 6?
> >
> > I don't view a group of people putting bug fixes into a micro
> > release as particularly conservative. If a group within the community
> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
> >
> > But let's put the releases into context, because I think it tells
> > a more interesting story.
> >
> > * hadoop 2.6.x = EOLed JREs (6,7)
> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
> > * hadoop 3.x = JRE 8
> > * hadoop 4.x = JRE 9
> >
> > There are groups of people still using JDK6 and they want bug
> > fixes in a maintenance release. Boom, there's 2.6.x.
> >
> > Hadoop 3.x has been pushed off for years for "reasons". So we
> > still have releases coming off of branch-2. If 2.7 had been released as
> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
> > weird wart in the middle of that supports JDK7 and JDK8. Given the
> public
> > policy and roadmaps of at least one major vendor at the time of this
> > writing, we should expect to see JDK7 support for at least the next two
> > years after 3.x appears. Bang, there's 2.x, where x is some large number.
> >
> > Then there is the future. People using JRE 8 want to use newer
> > dependencies. A reasonable request. Some of these dependency updates
> won't
> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
> compatible
> > way without breaking the universe. (Tons of JIRAs on this point.) This
> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
> > Kapow, there's 3.x
> >
> > The log4j community has stated that v1 won't work with JDK9. In
> > turn, this means we'll need to upgrade to v2 at some point. Upgrading to
> > v2 will break the log4j properties file (and maybe other things?).
> Another
> > incompatible change and it likely won't appear until Apache Hadoop v4
> > unless someone takes the initiative to fix it before v3 hits store
> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
> >
> > Having major release cadences tied to JRE updates isn't
> > necessarily a bad thing and definitely forces the community to a)
> actually
> > stop beating around the bush on majors and b) actually makes it
> relatively
> > easy to determine what the schedule looks like to some degree.
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >
> >
>
Re: [Release thread] 2.6.5 release activities
Posted by Sangjin Lee <sj...@apache.org>.
Thanks Chris!
I'll help Chris to get those JIRAs marked in his spreadsheet committed.
We'll cut the release branch shortly after that. If you have any critical
change that should be made part of 2.6.5 (CVE patches included), please
reach out to us and commit the changes. If all things go well, we'd like to
cut the branch in a few days.
Thanks,
Sangjin
On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
> Hi all,
>
> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>
> Here is what has been done so far:
>
> 1. I have gone through all of the potential backports and recorded the
> commit hashes for each of them from the branch that seems the most
> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
> from the backport).
>
> 2. I verified if the cherry pick for each commit is clean. This was best
> effort as some of the patches are in parts of the code that I am less
> familiar with. This is recorded in the public spread sheet here:
> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>
> I am going to need help from committers to get these backports committed.
> If there are any committers that have some spare cycles, especially if you
> were involved with the initial commit for one of these issues, please look
> at the spreadsheet and volunteer to backport one of the issues.
>
> As always, please let me know if you have any questions or feel that I have
> missed something.
>
> Thank you!
> Chris Trezzo
>
> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
> aw@effectivemachines.com
> > wrote:
>
> >
> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
> > >
> > > In this community, we are so aggressive to drop Java 7 support in
> 3.0.x
> > release. Here, why we are so conservative to keep releasing new bits to
> > support Java 6?
> >
> > I don't view a group of people putting bug fixes into a micro
> > release as particularly conservative. If a group within the community
> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
> >
> > But let's put the releases into context, because I think it tells
> > a more interesting story.
> >
> > * hadoop 2.6.x = EOLed JREs (6,7)
> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
> > * hadoop 3.x = JRE 8
> > * hadoop 4.x = JRE 9
> >
> > There are groups of people still using JDK6 and they want bug
> > fixes in a maintenance release. Boom, there's 2.6.x.
> >
> > Hadoop 3.x has been pushed off for years for "reasons". So we
> > still have releases coming off of branch-2. If 2.7 had been released as
> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
> > weird wart in the middle of that supports JDK7 and JDK8. Given the
> public
> > policy and roadmaps of at least one major vendor at the time of this
> > writing, we should expect to see JDK7 support for at least the next two
> > years after 3.x appears. Bang, there's 2.x, where x is some large number.
> >
> > Then there is the future. People using JRE 8 want to use newer
> > dependencies. A reasonable request. Some of these dependency updates
> won't
> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
> compatible
> > way without breaking the universe. (Tons of JIRAs on this point.) This
> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
> > Kapow, there's 3.x
> >
> > The log4j community has stated that v1 won't work with JDK9. In
> > turn, this means we'll need to upgrade to v2 at some point. Upgrading to
> > v2 will break the log4j properties file (and maybe other things?).
> Another
> > incompatible change and it likely won't appear until Apache Hadoop v4
> > unless someone takes the initiative to fix it before v3 hits store
> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
> >
> > Having major release cadences tied to JRE updates isn't
> > necessarily a bad thing and definitely forces the community to a)
> actually
> > stop beating around the bush on majors and b) actually makes it
> relatively
> > easy to determine what the schedule looks like to some degree.
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >
> >
>
Re: [Release thread] 2.6.5 release activities
Posted by Sangjin Lee <sj...@apache.org>.
Thanks Chris!
I'll help Chris to get those JIRAs marked in his spreadsheet committed.
We'll cut the release branch shortly after that. If you have any critical
change that should be made part of 2.6.5 (CVE patches included), please
reach out to us and commit the changes. If all things go well, we'd like to
cut the branch in a few days.
Thanks,
Sangjin
On Fri, Sep 9, 2016 at 1:24 PM, Chris Trezzo <ct...@gmail.com> wrote:
> Hi all,
>
> I wanted to give an update on the Hadoop 2.6.5 release efforts.
>
> Here is what has been done so far:
>
> 1. I have gone through all of the potential backports and recorded the
> commit hashes for each of them from the branch that seems the most
> appropriate (i.e. if there was a backport to 2.7.x then I used the hash
> from the backport).
>
> 2. I verified if the cherry pick for each commit is clean. This was best
> effort as some of the patches are in parts of the code that I am less
> familiar with. This is recorded in the public spread sheet here:
> https://docs.google.com/spreadsheets/d/1lfG2CYQ7W4q3ol
> WpOCo6EBAey1WYC8hTRUemHvYPPzY/edit?usp=sharing
>
> I am going to need help from committers to get these backports committed.
> If there are any committers that have some spare cycles, especially if you
> were involved with the initial commit for one of these issues, please look
> at the spreadsheet and volunteer to backport one of the issues.
>
> As always, please let me know if you have any questions or feel that I have
> missed something.
>
> Thank you!
> Chris Trezzo
>
> On Mon, Aug 15, 2016 at 10:55 AM, Allen Wittenauer <
> aw@effectivemachines.com
> > wrote:
>
> >
> > > On Aug 12, 2016, at 8:19 AM, Junping Du <jd...@hortonworks.com> wrote:
> > >
> > > In this community, we are so aggressive to drop Java 7 support in
> 3.0.x
> > release. Here, why we are so conservative to keep releasing new bits to
> > support Java 6?
> >
> > I don't view a group of people putting bug fixes into a micro
> > release as particularly conservative. If a group within the community
> > wasn't interested in doing it, 2.6.5 wouldn't be happening.
> >
> > But let's put the releases into context, because I think it tells
> > a more interesting story.
> >
> > * hadoop 2.6.x = EOLed JREs (6,7)
> > * hadoop 2.7 -> hadoop 2.x = transitional (7,8)
> > * hadoop 3.x = JRE 8
> > * hadoop 4.x = JRE 9
> >
> > There are groups of people still using JDK6 and they want bug
> > fixes in a maintenance release. Boom, there's 2.6.x.
> >
> > Hadoop 3.x has been pushed off for years for "reasons". So we
> > still have releases coming off of branch-2. If 2.7 had been released as
> > 3.x, this chart would look less weird. But it wasn't thus 2.x has this
> > weird wart in the middle of that supports JDK7 and JDK8. Given the
> public
> > policy and roadmaps of at least one major vendor at the time of this
> > writing, we should expect to see JDK7 support for at least the next two
> > years after 3.x appears. Bang, there's 2.x, where x is some large number.
> >
> > Then there is the future. People using JRE 8 want to use newer
> > dependencies. A reasonable request. Some of these dependency updates
> won't
> > work with JRE 7. We can't do that in hadoop 2.x in any sort of
> compatible
> > way without breaking the universe. (Tons of JIRAs on this point.) This
> > means we can only do it in 3.x (re: Hadoop Compatibility Guidelines).
> > Kapow, there's 3.x
> >
> > The log4j community has stated that v1 won't work with JDK9. In
> > turn, this means we'll need to upgrade to v2 at some point. Upgrading to
> > v2 will break the log4j properties file (and maybe other things?).
> Another
> > incompatible change and it likely won't appear until Apache Hadoop v4
> > unless someone takes the initiative to fix it before v3 hits store
> > shelves. This makes JDK9 the likely target for Apache Hadoop v4.
> >
> > Having major release cadences tied to JRE updates isn't
> > necessarily a bad thing and definitely forces the community to a)
> actually
> > stop beating around the bush on majors and b) actually makes it
> relatively
> > easy to determine what the schedule looks like to some degree.
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >
> >
>