> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ctre...@gmail.com> wrote:
>
> Thanks Sangjin for pushing this forward! I have a few questions:
These are great questions, because I know I'm not seeing a whole lot of
substance in this vote. The way to EOL software in the open source universe is
with new releases and aging it out. If someone wants to be a RE for a new
branch-1 release, more power to them. As volunteers to the ASF, we're not on
the hook to provide much actual support. This feels more like a vendor play
than a community one. But if the PMC want to vote on it, whatever. It won't
be first bylaw that doesn't really mean much.
> 1. What is the definition of end-of-life for a release in the hadoop
> project? My current understanding is as follows: When a release line
> reaches end-of-life, there are no more planned releases for that line.
> Committers are no longer responsible for back-porting bug fixes to the line
> (including fixed security vulnerabilities) and it is essentially
> unmaintained.
Just a point of clarification. There is no policy that says that
committers must back port. It's up to the individual committers to push a
change onto any particular branch. Therefore, this vote doesn't really change
anything in terms of committer responsibilities here.
> 2. How do major releases affect the end-of-life proposal? For example, how
> does a new minor release in the next major release affect the end-of-life
> of minor releases in a previous major release? Is it possible to have a
> maintained 2.x release if there is a 3.3 release?
I'm looking forward to seeing this answer too, given that 2.7.0 is
probably past the 2 year mark, 2.8.0 has seemingly been in a holding pattern
for over a year, and the next 3.0.0 alpha should be RSN....
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
