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 Sangjin Lee <sj...@apache.org> on 2017/01/17 16:35:57 UTC
[VOTE] Release cadence and EOL
Following up on the discussion thread on this topic (
https://s.apache.org/eFOf), I'd like to put the proposal for a vote for the
release cadence and EOL. The proposal is as follows:
"A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so."
This also entails that we the Hadoop community commit to following this
practice and solving challenges to make it possible. Andrew Wang laid out
some of those challenges and what can be done in the discussion thread
mentioned above.
I'll set the voting period to 7 days. I understand a majority rule would
apply in this case. Your vote is greatly appreciated, and so are
suggestions!
Thanks,
Sangjin
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
I'm going to stop the vote and go back to the discussion. It shouldn't be a
big surprise given the reservation we have so far.
I do hope there will be some actionable outcome as a result of that
discussion.
Regards,
Sangjin
On Mon, Jan 23, 2017 at 8:17 AM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
> >
> > 3. RM: some method to madness. Junping, for instance, is trying to roll
> > a release with 2300 patches. It is a huge time investment. (Thanks
> again,
> > Junping.) Smaller releases are easier to manage. A target release
> cadence,
> > coupled with a process that encourages volunteering, IMO would lead to
> more
> > committers doing releases.
>
>
> In the case of 2.8.0, that's on the original RM and "back port
> fever" that inflicts way too many committers. 2.8.0 has been sitting in a
> separate branch for over a year. Of *course* it is going to be a
> disaster. If the original RM had said "I don't have time, someone take
> over" after 3 months of it being left idle or another committer feeling as
> though they could take it or not everyone dumping everything they can in
> every release possible, it wouldn't be nearly as bad.
>
> Not only do we need to encourage volunteering, but we also need to
> encourage people to relinquish control. If the PMC wants to enact a
> cadence, then they also must be willing to step in when an RM is
> unresponsive and request someone else take over. A message every three
> months saying "Yes, I'm still working on it." doesn't really help anyone,
> including the RM.
>
>
> > To conclude, the biggest value I see is us (the community) agreeing on
> good
> > practices for our releases and work towards that. Writing it down
> somewhere
> > makes it a little more formal like the compatibility stuff, even if it is
> > not enforceable.
>
> So it's exactly like the compatibility stuff. ;)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
I'm going to stop the vote and go back to the discussion. It shouldn't be a
big surprise given the reservation we have so far.
I do hope there will be some actionable outcome as a result of that
discussion.
Regards,
Sangjin
On Mon, Jan 23, 2017 at 8:17 AM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
> >
> > 3. RM: some method to madness. Junping, for instance, is trying to roll
> > a release with 2300 patches. It is a huge time investment. (Thanks
> again,
> > Junping.) Smaller releases are easier to manage. A target release
> cadence,
> > coupled with a process that encourages volunteering, IMO would lead to
> more
> > committers doing releases.
>
>
> In the case of 2.8.0, that's on the original RM and "back port
> fever" that inflicts way too many committers. 2.8.0 has been sitting in a
> separate branch for over a year. Of *course* it is going to be a
> disaster. If the original RM had said "I don't have time, someone take
> over" after 3 months of it being left idle or another committer feeling as
> though they could take it or not everyone dumping everything they can in
> every release possible, it wouldn't be nearly as bad.
>
> Not only do we need to encourage volunteering, but we also need to
> encourage people to relinquish control. If the PMC wants to enact a
> cadence, then they also must be willing to step in when an RM is
> unresponsive and request someone else take over. A message every three
> months saying "Yes, I'm still working on it." doesn't really help anyone,
> including the RM.
>
>
> > To conclude, the biggest value I see is us (the community) agreeing on
> good
> > practices for our releases and work towards that. Writing it down
> somewhere
> > makes it a little more formal like the compatibility stuff, even if it is
> > not enforceable.
>
> So it's exactly like the compatibility stuff. ;)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
I'm going to stop the vote and go back to the discussion. It shouldn't be a
big surprise given the reservation we have so far.
I do hope there will be some actionable outcome as a result of that
discussion.
Regards,
Sangjin
On Mon, Jan 23, 2017 at 8:17 AM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
> >
> > 3. RM: some method to madness. Junping, for instance, is trying to roll
> > a release with 2300 patches. It is a huge time investment. (Thanks
> again,
> > Junping.) Smaller releases are easier to manage. A target release
> cadence,
> > coupled with a process that encourages volunteering, IMO would lead to
> more
> > committers doing releases.
>
>
> In the case of 2.8.0, that's on the original RM and "back port
> fever" that inflicts way too many committers. 2.8.0 has been sitting in a
> separate branch for over a year. Of *course* it is going to be a
> disaster. If the original RM had said "I don't have time, someone take
> over" after 3 months of it being left idle or another committer feeling as
> though they could take it or not everyone dumping everything they can in
> every release possible, it wouldn't be nearly as bad.
>
> Not only do we need to encourage volunteering, but we also need to
> encourage people to relinquish control. If the PMC wants to enact a
> cadence, then they also must be willing to step in when an RM is
> unresponsive and request someone else take over. A message every three
> months saying "Yes, I'm still working on it." doesn't really help anyone,
> including the RM.
>
>
> > To conclude, the biggest value I see is us (the community) agreeing on
> good
> > practices for our releases and work towards that. Writing it down
> somewhere
> > makes it a little more formal like the compatibility stuff, even if it is
> > not enforceable.
>
> So it's exactly like the compatibility stuff. ;)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
I'm going to stop the vote and go back to the discussion. It shouldn't be a
big surprise given the reservation we have so far.
I do hope there will be some actionable outcome as a result of that
discussion.
Regards,
Sangjin
On Mon, Jan 23, 2017 at 8:17 AM, Allen Wittenauer <aw...@effectivemachines.com>
wrote:
>
> > On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <ka...@cloudera.com>
> wrote:
> >
> > 3. RM: some method to madness. Junping, for instance, is trying to roll
> > a release with 2300 patches. It is a huge time investment. (Thanks
> again,
> > Junping.) Smaller releases are easier to manage. A target release
> cadence,
> > coupled with a process that encourages volunteering, IMO would lead to
> more
> > committers doing releases.
>
>
> In the case of 2.8.0, that's on the original RM and "back port
> fever" that inflicts way too many committers. 2.8.0 has been sitting in a
> separate branch for over a year. Of *course* it is going to be a
> disaster. If the original RM had said "I don't have time, someone take
> over" after 3 months of it being left idle or another committer feeling as
> though they could take it or not everyone dumping everything they can in
> every release possible, it wouldn't be nearly as bad.
>
> Not only do we need to encourage volunteering, but we also need to
> encourage people to relinquish control. If the PMC wants to enact a
> cadence, then they also must be willing to step in when an RM is
> unresponsive and request someone else take over. A message every three
> months saying "Yes, I'm still working on it." doesn't really help anyone,
> including the RM.
>
>
> > To conclude, the biggest value I see is us (the community) agreeing on
> good
> > practices for our releases and work towards that. Writing it down
> somewhere
> > makes it a little more formal like the compatibility stuff, even if it is
> > not enforceable.
>
> So it's exactly like the compatibility stuff. ;)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <ka...@cloudera.com> wrote:
>
> 3. RM: some method to madness. Junping, for instance, is trying to roll
> a release with 2300 patches. It is a huge time investment. (Thanks again,
> Junping.) Smaller releases are easier to manage. A target release cadence,
> coupled with a process that encourages volunteering, IMO would lead to more
> committers doing releases.
In the case of 2.8.0, that's on the original RM and "back port fever" that inflicts way too many committers. 2.8.0 has been sitting in a separate branch for over a year. Of *course* it is going to be a disaster. If the original RM had said "I don't have time, someone take over" after 3 months of it being left idle or another committer feeling as though they could take it or not everyone dumping everything they can in every release possible, it wouldn't be nearly as bad.
Not only do we need to encourage volunteering, but we also need to encourage people to relinquish control. If the PMC wants to enact a cadence, then they also must be willing to step in when an RM is unresponsive and request someone else take over. A message every three months saying "Yes, I'm still working on it." doesn't really help anyone, including the RM.
> To conclude, the biggest value I see is us (the community) agreeing on good
> practices for our releases and work towards that. Writing it down somewhere
> makes it a little more formal like the compatibility stuff, even if it is
> not enforceable.
So it's exactly like the compatibility stuff. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <ka...@cloudera.com> wrote:
>
> 3. RM: some method to madness. Junping, for instance, is trying to roll
> a release with 2300 patches. It is a huge time investment. (Thanks again,
> Junping.) Smaller releases are easier to manage. A target release cadence,
> coupled with a process that encourages volunteering, IMO would lead to more
> committers doing releases.
In the case of 2.8.0, that's on the original RM and "back port fever" that inflicts way too many committers. 2.8.0 has been sitting in a separate branch for over a year. Of *course* it is going to be a disaster. If the original RM had said "I don't have time, someone take over" after 3 months of it being left idle or another committer feeling as though they could take it or not everyone dumping everything they can in every release possible, it wouldn't be nearly as bad.
Not only do we need to encourage volunteering, but we also need to encourage people to relinquish control. If the PMC wants to enact a cadence, then they also must be willing to step in when an RM is unresponsive and request someone else take over. A message every three months saying "Yes, I'm still working on it." doesn't really help anyone, including the RM.
> To conclude, the biggest value I see is us (the community) agreeing on good
> practices for our releases and work towards that. Writing it down somewhere
> makes it a little more formal like the compatibility stuff, even if it is
> not enforceable.
So it's exactly like the compatibility stuff. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <ka...@cloudera.com> wrote:
>
> 3. RM: some method to madness. Junping, for instance, is trying to roll
> a release with 2300 patches. It is a huge time investment. (Thanks again,
> Junping.) Smaller releases are easier to manage. A target release cadence,
> coupled with a process that encourages volunteering, IMO would lead to more
> committers doing releases.
In the case of 2.8.0, that's on the original RM and "back port fever" that inflicts way too many committers. 2.8.0 has been sitting in a separate branch for over a year. Of *course* it is going to be a disaster. If the original RM had said "I don't have time, someone take over" after 3 months of it being left idle or another committer feeling as though they could take it or not everyone dumping everything they can in every release possible, it wouldn't be nearly as bad.
Not only do we need to encourage volunteering, but we also need to encourage people to relinquish control. If the PMC wants to enact a cadence, then they also must be willing to step in when an RM is unresponsive and request someone else take over. A message every three months saying "Yes, I'm still working on it." doesn't really help anyone, including the RM.
> To conclude, the biggest value I see is us (the community) agreeing on good
> practices for our releases and work towards that. Writing it down somewhere
> makes it a little more formal like the compatibility stuff, even if it is
> not enforceable.
So it's exactly like the compatibility stuff. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jan 21, 2017, at 7:08 PM, Karthik Kambatla <ka...@cloudera.com> wrote:
>
> 3. RM: some method to madness. Junping, for instance, is trying to roll
> a release with 2300 patches. It is a huge time investment. (Thanks again,
> Junping.) Smaller releases are easier to manage. A target release cadence,
> coupled with a process that encourages volunteering, IMO would lead to more
> committers doing releases.
In the case of 2.8.0, that's on the original RM and "back port fever" that inflicts way too many committers. 2.8.0 has been sitting in a separate branch for over a year. Of *course* it is going to be a disaster. If the original RM had said "I don't have time, someone take over" after 3 months of it being left idle or another committer feeling as though they could take it or not everyone dumping everything they can in every release possible, it wouldn't be nearly as bad.
Not only do we need to encourage volunteering, but we also need to encourage people to relinquish control. If the PMC wants to enact a cadence, then they also must be willing to step in when an RM is unresponsive and request someone else take over. A message every three months saying "Yes, I'm still working on it." doesn't really help anyone, including the RM.
> To conclude, the biggest value I see is us (the community) agreeing on good
> practices for our releases and work towards that. Writing it down somewhere
> makes it a little more formal like the compatibility stuff, even if it is
> not enforceable.
So it's exactly like the compatibility stuff. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
Given the discussions, I feel we are not ready for VOTE on this yet.
Sangjin, should we go back to the DISCUSS thread?
IMO, these are guidelines and not policies we want to enforce. Maybe, the
text should say something along the lines of: "The Hadoop community is
inclined to". And, maybe, a caveat that these inclinations will be acted
upon based on the release in question, its adoption and the availability of
committer volunteers.
As I said on the DISCUSS thread, IMO, these guidelines are very useful and
form a good baseline to operate from as Sangjin said. Also, I don't see any
disadvantages of having this baseline.
Here are the advantages I see.
1. Users know what to expect in terms of security fixes, critical bug
fixes and can plan their upgrades accordingly.
2. Contributors don't need to panic about getting a feature/improvement
in *this* release, because they know the next one is only 6 months away.
3. RM: some method to madness. Junping, for instance, is trying to roll
a release with 2300 patches. It is a huge time investment. (Thanks again,
Junping.) Smaller releases are easier to manage. A target release cadence,
coupled with a process that encourages volunteering, IMO would lead to more
committers doing releases.
To conclude, the biggest value I see is us (the community) agreeing on good
practices for our releases and work towards that. Writing it down somewhere
makes it a little more formal like the compatibility stuff, even if it is
not enforceable.
On Sat, Jan 21, 2017 at 11:36 AM, Chris Douglas <cd...@apache.org> wrote:
> On Fri, Jan 20, 2017 at 2:50 PM, Sangjin Lee <sj...@apache.org> wrote:
> > The security patch for the 2.6.x line is a case in point. Without any
> > guideline, we would start with "What should we do for 2.6.x? Should we
> > continue to patch it?" With this guideline, the baseline is already "it's
> > been 2 years since 2.6.0 is released and we should consider stopping
> > releasing from 2.6.x and encourage users to upgrade to 2.7.x."
>
> Unless it falls under the "good reason" clause. To invent an example,
> if 3.6.x were within the two year/minor release window, but 3.5.x was
> more widely deployed/stable, then we'd use this escape hatch to patch
> 3.5.x and likely just violate our policy on 3.6.x (when the
> implementation cost is high). How do we "force" a fix to 3.6.x?
>
> We can't actually compel work from people. Even when we can point to a
> prior consensus, someone needs to be motivated to actually complete
> that task. That's the rub: this proposal doesn't only allow us to stop
> working on old code, it also promises that we'll work on code we want
> to abandon.
>
> Pointing to a bylaw, and telling a contributor they "must" support a
> branch/release isn't going to result in shorter discussions, either.
> In the preceding hypothetical, if someone wants a fix in the 3.6 line,
> they either need to convince others that it's important or they need
> to do the work themselves.
>
> > Actually the decision on security issues is a pretty strong indicator of
> our
> > desire for EOL. If we say we do not want to patch that line for security
> > vulnerability, then there would be even *less* rationale for fixing any
> > other issue on that line. So the decision to stop backporting security
> > patches is a sufficient indication of EOL in my mind.
>
> Agreed. If we're not backporting security patches to a branch, then we
> need to release a CVE, file a JIRA, and move on. If someone wants to
> fix it and roll an RC for that release line, it lives. Otherwise it
> dies as people move to later versions (unpatched security flaws are
> motivating). A branch is EOL when we stop releasing from it. Two years
> or two minor releases is a good heuristic based on recent history, but
> overfitting policy to experience doesn't seem to buy us anything.
>
> I'm all for spending less time discussing release criteria, but if
> it's sufficient to observe which release lines are getting updates and
> label them accordingly, that's cheaper to implement than a curated set
> of constraints. -C
>
> >> We can still embargo security flaws if someone asks (to give them time
> >> time to implement a fix and call a vote). If there's nothing else in
> >> the release, then we're effectively announcing it. In those cases, we
> >> call a vote on private@ (cc: security@). -C
> >>
> >>
> >> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
> >> wrote:
> >> > I don't think the motivation here is vendor play or taking away power
> >> > from
> >> > committers. Having a regular release cadence helps our users
> understand
> >> > when a feature will ship so they can plan their upgrades. Having an
> EOL
> >> > policy and a minimum support period helps users choose a release line,
> >> > and
> >> > understand when they will need to upgrade.
> >> >
> >> > In the earlier thread, we discussed how these are not rules, but
> >> > guidelines. There's a lot of flexibility if someone wants to keep
> >> > maintaining a release line (particularly if they are willing to do the
> >> > backporting work). More power to them; more releases are a good thing
> >> > for
> >> > the project.
> >> >
> >> > My main concern (which I raised on the earlier thread) is that without
> >> > significant improvements to the release process and upstream
> integration
> >> > testing, it's unlikely we'll actually ship more releases. Too often,
> >> > branches are simply not in a releaseable state, or they have latent
> >> > blocker
> >> > bugs due to a lack of testing. This is what we've been struggling with
> >> > on
> >> > both the 2.8.x and 3.0.0-x release lines.
> >> >
> >> > So, in the abstract, I'm +1 on having a published policy on release
> >> > cadence
> >> > and EOL. This information helps users.
> >> >
> >> > However, I don't think we're ready to actually execute on this policy
> >> > for
> >> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
> >> > publishing a policy we don't follow is more confusing to users.
> >> >
> >> > My 2c,
> >> > Andrew
> >> >
> >> >
> >> >
> >> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal
> >> > <aa...@hortonworks.com>
> >> > wrote:
> >> >
> >> >> The ASF release policy says releases may not be vetoed [1] so the EOL
> >> >> policy sounds unenforceable. Not sure a release cadence is
> enforceable
> >> >> either since Release Managers are volunteers.
> >> >>
> >> >> 1. https://www.apache.org/dev/release.html#approving-a-release
> >> >>
> >> >>
> >> >>
> >> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
> >> >>
> >> >> +1 on Sangjin's proposal -
> >> >> "A minor release line is end-of-lifed 2 years after it is
> released
> >> >> or
> >> >> there
> >> >> are 2 newer minor releases, whichever is sooner. The community
> >> >> reserves the
> >> >> right to extend or shorten the life of a release line if there
> is a
> >> >> good
> >> >> reason to do so."
> >> >>
> >> >> I also noticed Karthik bring up some new proposals - some of them
> >> >> looks interesting to me and I have some ideas as well. Karthik, can
> you
> >> >> bring it out in a separated discussion threads so that we can discuss
> >> >> from
> >> >> there?
> >> >>
> >> >> About Chris Trezzo's question about definition of EOL of hadoop
> >> >> release, I think potentially changes could be:
> >> >> 1. For users of Apache hadoop, they would expect to upgrade to a
> >> >> new
> >> >> minor/major releases after EOL of their current release because there
> >> >> is no
> >> >> guarantee of new maintenance release.
> >> >>
> >> >> 2. For release effort, apache law claim that committer can
> >> >> volunteer
> >> >> RM for any release. With this release EOL proposal passes and written
> >> >> into
> >> >> hadoop bylaw, anyone want to call for a release which is EOL then
> >> >> she/he
> >> >> have to provide a good reason to community and get voted before to
> >> >> start
> >> >> release effort. We don't want to waste community time/resource to
> >> >> verify/vote a narrow interested release.
> >> >>
> >> >> 3. About committer's responsibility, I think the bottom line is
> >> >> committer should commit patch contributor's target release and
> her/his
> >> >> own
> >> >> interest release which I conservatively agree with Allen's point that
> >> >> this
> >> >> vote doesn't change anything. But if a committer want to take care
> more
> >> >> interest from the whole community like most committers are doing
> today,
> >> >> he/she should understand which branches can benefit more people and
> >> >> could
> >> >> skip some EOL release branches for backport effort.
> >> >>
> >> >> About major release EOL, this could be more complicated and I
> think
> >> >> we
> >> >> should discuss separately.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Junping
> >> >> ________________________________________
> >> >> From: Allen Wittenauer <aw...@effectivemachines.com>
> >> >> Sent: Wednesday, January 18, 2017 3:30 PM
> >> >> To: Chris Trezzo
> >> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> >> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> >> >> Subject: Re: [VOTE] Release cadence and EOL
> >> >>
> >> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> >> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >> >>
> >> >>
> >> >>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> >> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
Given the discussions, I feel we are not ready for VOTE on this yet.
Sangjin, should we go back to the DISCUSS thread?
IMO, these are guidelines and not policies we want to enforce. Maybe, the
text should say something along the lines of: "The Hadoop community is
inclined to". And, maybe, a caveat that these inclinations will be acted
upon based on the release in question, its adoption and the availability of
committer volunteers.
As I said on the DISCUSS thread, IMO, these guidelines are very useful and
form a good baseline to operate from as Sangjin said. Also, I don't see any
disadvantages of having this baseline.
Here are the advantages I see.
1. Users know what to expect in terms of security fixes, critical bug
fixes and can plan their upgrades accordingly.
2. Contributors don't need to panic about getting a feature/improvement
in *this* release, because they know the next one is only 6 months away.
3. RM: some method to madness. Junping, for instance, is trying to roll
a release with 2300 patches. It is a huge time investment. (Thanks again,
Junping.) Smaller releases are easier to manage. A target release cadence,
coupled with a process that encourages volunteering, IMO would lead to more
committers doing releases.
To conclude, the biggest value I see is us (the community) agreeing on good
practices for our releases and work towards that. Writing it down somewhere
makes it a little more formal like the compatibility stuff, even if it is
not enforceable.
On Sat, Jan 21, 2017 at 11:36 AM, Chris Douglas <cd...@apache.org> wrote:
> On Fri, Jan 20, 2017 at 2:50 PM, Sangjin Lee <sj...@apache.org> wrote:
> > The security patch for the 2.6.x line is a case in point. Without any
> > guideline, we would start with "What should we do for 2.6.x? Should we
> > continue to patch it?" With this guideline, the baseline is already "it's
> > been 2 years since 2.6.0 is released and we should consider stopping
> > releasing from 2.6.x and encourage users to upgrade to 2.7.x."
>
> Unless it falls under the "good reason" clause. To invent an example,
> if 3.6.x were within the two year/minor release window, but 3.5.x was
> more widely deployed/stable, then we'd use this escape hatch to patch
> 3.5.x and likely just violate our policy on 3.6.x (when the
> implementation cost is high). How do we "force" a fix to 3.6.x?
>
> We can't actually compel work from people. Even when we can point to a
> prior consensus, someone needs to be motivated to actually complete
> that task. That's the rub: this proposal doesn't only allow us to stop
> working on old code, it also promises that we'll work on code we want
> to abandon.
>
> Pointing to a bylaw, and telling a contributor they "must" support a
> branch/release isn't going to result in shorter discussions, either.
> In the preceding hypothetical, if someone wants a fix in the 3.6 line,
> they either need to convince others that it's important or they need
> to do the work themselves.
>
> > Actually the decision on security issues is a pretty strong indicator of
> our
> > desire for EOL. If we say we do not want to patch that line for security
> > vulnerability, then there would be even *less* rationale for fixing any
> > other issue on that line. So the decision to stop backporting security
> > patches is a sufficient indication of EOL in my mind.
>
> Agreed. If we're not backporting security patches to a branch, then we
> need to release a CVE, file a JIRA, and move on. If someone wants to
> fix it and roll an RC for that release line, it lives. Otherwise it
> dies as people move to later versions (unpatched security flaws are
> motivating). A branch is EOL when we stop releasing from it. Two years
> or two minor releases is a good heuristic based on recent history, but
> overfitting policy to experience doesn't seem to buy us anything.
>
> I'm all for spending less time discussing release criteria, but if
> it's sufficient to observe which release lines are getting updates and
> label them accordingly, that's cheaper to implement than a curated set
> of constraints. -C
>
> >> We can still embargo security flaws if someone asks (to give them time
> >> time to implement a fix and call a vote). If there's nothing else in
> >> the release, then we're effectively announcing it. In those cases, we
> >> call a vote on private@ (cc: security@). -C
> >>
> >>
> >> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
> >> wrote:
> >> > I don't think the motivation here is vendor play or taking away power
> >> > from
> >> > committers. Having a regular release cadence helps our users
> understand
> >> > when a feature will ship so they can plan their upgrades. Having an
> EOL
> >> > policy and a minimum support period helps users choose a release line,
> >> > and
> >> > understand when they will need to upgrade.
> >> >
> >> > In the earlier thread, we discussed how these are not rules, but
> >> > guidelines. There's a lot of flexibility if someone wants to keep
> >> > maintaining a release line (particularly if they are willing to do the
> >> > backporting work). More power to them; more releases are a good thing
> >> > for
> >> > the project.
> >> >
> >> > My main concern (which I raised on the earlier thread) is that without
> >> > significant improvements to the release process and upstream
> integration
> >> > testing, it's unlikely we'll actually ship more releases. Too often,
> >> > branches are simply not in a releaseable state, or they have latent
> >> > blocker
> >> > bugs due to a lack of testing. This is what we've been struggling with
> >> > on
> >> > both the 2.8.x and 3.0.0-x release lines.
> >> >
> >> > So, in the abstract, I'm +1 on having a published policy on release
> >> > cadence
> >> > and EOL. This information helps users.
> >> >
> >> > However, I don't think we're ready to actually execute on this policy
> >> > for
> >> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
> >> > publishing a policy we don't follow is more confusing to users.
> >> >
> >> > My 2c,
> >> > Andrew
> >> >
> >> >
> >> >
> >> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal
> >> > <aa...@hortonworks.com>
> >> > wrote:
> >> >
> >> >> The ASF release policy says releases may not be vetoed [1] so the EOL
> >> >> policy sounds unenforceable. Not sure a release cadence is
> enforceable
> >> >> either since Release Managers are volunteers.
> >> >>
> >> >> 1. https://www.apache.org/dev/release.html#approving-a-release
> >> >>
> >> >>
> >> >>
> >> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
> >> >>
> >> >> +1 on Sangjin's proposal -
> >> >> "A minor release line is end-of-lifed 2 years after it is
> released
> >> >> or
> >> >> there
> >> >> are 2 newer minor releases, whichever is sooner. The community
> >> >> reserves the
> >> >> right to extend or shorten the life of a release line if there
> is a
> >> >> good
> >> >> reason to do so."
> >> >>
> >> >> I also noticed Karthik bring up some new proposals - some of them
> >> >> looks interesting to me and I have some ideas as well. Karthik, can
> you
> >> >> bring it out in a separated discussion threads so that we can discuss
> >> >> from
> >> >> there?
> >> >>
> >> >> About Chris Trezzo's question about definition of EOL of hadoop
> >> >> release, I think potentially changes could be:
> >> >> 1. For users of Apache hadoop, they would expect to upgrade to a
> >> >> new
> >> >> minor/major releases after EOL of their current release because there
> >> >> is no
> >> >> guarantee of new maintenance release.
> >> >>
> >> >> 2. For release effort, apache law claim that committer can
> >> >> volunteer
> >> >> RM for any release. With this release EOL proposal passes and written
> >> >> into
> >> >> hadoop bylaw, anyone want to call for a release which is EOL then
> >> >> she/he
> >> >> have to provide a good reason to community and get voted before to
> >> >> start
> >> >> release effort. We don't want to waste community time/resource to
> >> >> verify/vote a narrow interested release.
> >> >>
> >> >> 3. About committer's responsibility, I think the bottom line is
> >> >> committer should commit patch contributor's target release and
> her/his
> >> >> own
> >> >> interest release which I conservatively agree with Allen's point that
> >> >> this
> >> >> vote doesn't change anything. But if a committer want to take care
> more
> >> >> interest from the whole community like most committers are doing
> today,
> >> >> he/she should understand which branches can benefit more people and
> >> >> could
> >> >> skip some EOL release branches for backport effort.
> >> >>
> >> >> About major release EOL, this could be more complicated and I
> think
> >> >> we
> >> >> should discuss separately.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Junping
> >> >> ________________________________________
> >> >> From: Allen Wittenauer <aw...@effectivemachines.com>
> >> >> Sent: Wednesday, January 18, 2017 3:30 PM
> >> >> To: Chris Trezzo
> >> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> >> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> >> >> Subject: Re: [VOTE] Release cadence and EOL
> >> >>
> >> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> >> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >> >>
> >> >>
> >> >>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> >> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
Given the discussions, I feel we are not ready for VOTE on this yet.
Sangjin, should we go back to the DISCUSS thread?
IMO, these are guidelines and not policies we want to enforce. Maybe, the
text should say something along the lines of: "The Hadoop community is
inclined to". And, maybe, a caveat that these inclinations will be acted
upon based on the release in question, its adoption and the availability of
committer volunteers.
As I said on the DISCUSS thread, IMO, these guidelines are very useful and
form a good baseline to operate from as Sangjin said. Also, I don't see any
disadvantages of having this baseline.
Here are the advantages I see.
1. Users know what to expect in terms of security fixes, critical bug
fixes and can plan their upgrades accordingly.
2. Contributors don't need to panic about getting a feature/improvement
in *this* release, because they know the next one is only 6 months away.
3. RM: some method to madness. Junping, for instance, is trying to roll
a release with 2300 patches. It is a huge time investment. (Thanks again,
Junping.) Smaller releases are easier to manage. A target release cadence,
coupled with a process that encourages volunteering, IMO would lead to more
committers doing releases.
To conclude, the biggest value I see is us (the community) agreeing on good
practices for our releases and work towards that. Writing it down somewhere
makes it a little more formal like the compatibility stuff, even if it is
not enforceable.
On Sat, Jan 21, 2017 at 11:36 AM, Chris Douglas <cd...@apache.org> wrote:
> On Fri, Jan 20, 2017 at 2:50 PM, Sangjin Lee <sj...@apache.org> wrote:
> > The security patch for the 2.6.x line is a case in point. Without any
> > guideline, we would start with "What should we do for 2.6.x? Should we
> > continue to patch it?" With this guideline, the baseline is already "it's
> > been 2 years since 2.6.0 is released and we should consider stopping
> > releasing from 2.6.x and encourage users to upgrade to 2.7.x."
>
> Unless it falls under the "good reason" clause. To invent an example,
> if 3.6.x were within the two year/minor release window, but 3.5.x was
> more widely deployed/stable, then we'd use this escape hatch to patch
> 3.5.x and likely just violate our policy on 3.6.x (when the
> implementation cost is high). How do we "force" a fix to 3.6.x?
>
> We can't actually compel work from people. Even when we can point to a
> prior consensus, someone needs to be motivated to actually complete
> that task. That's the rub: this proposal doesn't only allow us to stop
> working on old code, it also promises that we'll work on code we want
> to abandon.
>
> Pointing to a bylaw, and telling a contributor they "must" support a
> branch/release isn't going to result in shorter discussions, either.
> In the preceding hypothetical, if someone wants a fix in the 3.6 line,
> they either need to convince others that it's important or they need
> to do the work themselves.
>
> > Actually the decision on security issues is a pretty strong indicator of
> our
> > desire for EOL. If we say we do not want to patch that line for security
> > vulnerability, then there would be even *less* rationale for fixing any
> > other issue on that line. So the decision to stop backporting security
> > patches is a sufficient indication of EOL in my mind.
>
> Agreed. If we're not backporting security patches to a branch, then we
> need to release a CVE, file a JIRA, and move on. If someone wants to
> fix it and roll an RC for that release line, it lives. Otherwise it
> dies as people move to later versions (unpatched security flaws are
> motivating). A branch is EOL when we stop releasing from it. Two years
> or two minor releases is a good heuristic based on recent history, but
> overfitting policy to experience doesn't seem to buy us anything.
>
> I'm all for spending less time discussing release criteria, but if
> it's sufficient to observe which release lines are getting updates and
> label them accordingly, that's cheaper to implement than a curated set
> of constraints. -C
>
> >> We can still embargo security flaws if someone asks (to give them time
> >> time to implement a fix and call a vote). If there's nothing else in
> >> the release, then we're effectively announcing it. In those cases, we
> >> call a vote on private@ (cc: security@). -C
> >>
> >>
> >> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
> >> wrote:
> >> > I don't think the motivation here is vendor play or taking away power
> >> > from
> >> > committers. Having a regular release cadence helps our users
> understand
> >> > when a feature will ship so they can plan their upgrades. Having an
> EOL
> >> > policy and a minimum support period helps users choose a release line,
> >> > and
> >> > understand when they will need to upgrade.
> >> >
> >> > In the earlier thread, we discussed how these are not rules, but
> >> > guidelines. There's a lot of flexibility if someone wants to keep
> >> > maintaining a release line (particularly if they are willing to do the
> >> > backporting work). More power to them; more releases are a good thing
> >> > for
> >> > the project.
> >> >
> >> > My main concern (which I raised on the earlier thread) is that without
> >> > significant improvements to the release process and upstream
> integration
> >> > testing, it's unlikely we'll actually ship more releases. Too often,
> >> > branches are simply not in a releaseable state, or they have latent
> >> > blocker
> >> > bugs due to a lack of testing. This is what we've been struggling with
> >> > on
> >> > both the 2.8.x and 3.0.0-x release lines.
> >> >
> >> > So, in the abstract, I'm +1 on having a published policy on release
> >> > cadence
> >> > and EOL. This information helps users.
> >> >
> >> > However, I don't think we're ready to actually execute on this policy
> >> > for
> >> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
> >> > publishing a policy we don't follow is more confusing to users.
> >> >
> >> > My 2c,
> >> > Andrew
> >> >
> >> >
> >> >
> >> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal
> >> > <aa...@hortonworks.com>
> >> > wrote:
> >> >
> >> >> The ASF release policy says releases may not be vetoed [1] so the EOL
> >> >> policy sounds unenforceable. Not sure a release cadence is
> enforceable
> >> >> either since Release Managers are volunteers.
> >> >>
> >> >> 1. https://www.apache.org/dev/release.html#approving-a-release
> >> >>
> >> >>
> >> >>
> >> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
> >> >>
> >> >> +1 on Sangjin's proposal -
> >> >> "A minor release line is end-of-lifed 2 years after it is
> released
> >> >> or
> >> >> there
> >> >> are 2 newer minor releases, whichever is sooner. The community
> >> >> reserves the
> >> >> right to extend or shorten the life of a release line if there
> is a
> >> >> good
> >> >> reason to do so."
> >> >>
> >> >> I also noticed Karthik bring up some new proposals - some of them
> >> >> looks interesting to me and I have some ideas as well. Karthik, can
> you
> >> >> bring it out in a separated discussion threads so that we can discuss
> >> >> from
> >> >> there?
> >> >>
> >> >> About Chris Trezzo's question about definition of EOL of hadoop
> >> >> release, I think potentially changes could be:
> >> >> 1. For users of Apache hadoop, they would expect to upgrade to a
> >> >> new
> >> >> minor/major releases after EOL of their current release because there
> >> >> is no
> >> >> guarantee of new maintenance release.
> >> >>
> >> >> 2. For release effort, apache law claim that committer can
> >> >> volunteer
> >> >> RM for any release. With this release EOL proposal passes and written
> >> >> into
> >> >> hadoop bylaw, anyone want to call for a release which is EOL then
> >> >> she/he
> >> >> have to provide a good reason to community and get voted before to
> >> >> start
> >> >> release effort. We don't want to waste community time/resource to
> >> >> verify/vote a narrow interested release.
> >> >>
> >> >> 3. About committer's responsibility, I think the bottom line is
> >> >> committer should commit patch contributor's target release and
> her/his
> >> >> own
> >> >> interest release which I conservatively agree with Allen's point that
> >> >> this
> >> >> vote doesn't change anything. But if a committer want to take care
> more
> >> >> interest from the whole community like most committers are doing
> today,
> >> >> he/she should understand which branches can benefit more people and
> >> >> could
> >> >> skip some EOL release branches for backport effort.
> >> >>
> >> >> About major release EOL, this could be more complicated and I
> think
> >> >> we
> >> >> should discuss separately.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Junping
> >> >> ________________________________________
> >> >> From: Allen Wittenauer <aw...@effectivemachines.com>
> >> >> Sent: Wednesday, January 18, 2017 3:30 PM
> >> >> To: Chris Trezzo
> >> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> >> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> >> >> Subject: Re: [VOTE] Release cadence and EOL
> >> >>
> >> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> >> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >> >>
> >> >>
> >> >>
> >> >> ------------------------------------------------------------
> ---------
> >> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> >> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Chris Douglas <cd...@apache.org>.
On Fri, Jan 20, 2017 at 2:50 PM, Sangjin Lee <sj...@apache.org> wrote:
> The security patch for the 2.6.x line is a case in point. Without any
> guideline, we would start with "What should we do for 2.6.x? Should we
> continue to patch it?" With this guideline, the baseline is already "it's
> been 2 years since 2.6.0 is released and we should consider stopping
> releasing from 2.6.x and encourage users to upgrade to 2.7.x."
Unless it falls under the "good reason" clause. To invent an example,
if 3.6.x were within the two year/minor release window, but 3.5.x was
more widely deployed/stable, then we'd use this escape hatch to patch
3.5.x and likely just violate our policy on 3.6.x (when the
implementation cost is high). How do we "force" a fix to 3.6.x?
We can't actually compel work from people. Even when we can point to a
prior consensus, someone needs to be motivated to actually complete
that task. That's the rub: this proposal doesn't only allow us to stop
working on old code, it also promises that we'll work on code we want
to abandon.
Pointing to a bylaw, and telling a contributor they "must" support a
branch/release isn't going to result in shorter discussions, either.
In the preceding hypothetical, if someone wants a fix in the 3.6 line,
they either need to convince others that it's important or they need
to do the work themselves.
> Actually the decision on security issues is a pretty strong indicator of our
> desire for EOL. If we say we do not want to patch that line for security
> vulnerability, then there would be even *less* rationale for fixing any
> other issue on that line. So the decision to stop backporting security
> patches is a sufficient indication of EOL in my mind.
Agreed. If we're not backporting security patches to a branch, then we
need to release a CVE, file a JIRA, and move on. If someone wants to
fix it and roll an RC for that release line, it lives. Otherwise it
dies as people move to later versions (unpatched security flaws are
motivating). A branch is EOL when we stop releasing from it. Two years
or two minor releases is a good heuristic based on recent history, but
overfitting policy to experience doesn't seem to buy us anything.
I'm all for spending less time discussing release criteria, but if
it's sufficient to observe which release lines are getting updates and
label them accordingly, that's cheaper to implement than a curated set
of constraints. -C
>> We can still embargo security flaws if someone asks (to give them time
>> time to implement a fix and call a vote). If there's nothing else in
>> the release, then we're effectively announcing it. In those cases, we
>> call a vote on private@ (cc: security@). -C
>>
>>
>> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> > I don't think the motivation here is vendor play or taking away power
>> > from
>> > committers. Having a regular release cadence helps our users understand
>> > when a feature will ship so they can plan their upgrades. Having an EOL
>> > policy and a minimum support period helps users choose a release line,
>> > and
>> > understand when they will need to upgrade.
>> >
>> > In the earlier thread, we discussed how these are not rules, but
>> > guidelines. There's a lot of flexibility if someone wants to keep
>> > maintaining a release line (particularly if they are willing to do the
>> > backporting work). More power to them; more releases are a good thing
>> > for
>> > the project.
>> >
>> > My main concern (which I raised on the earlier thread) is that without
>> > significant improvements to the release process and upstream integration
>> > testing, it's unlikely we'll actually ship more releases. Too often,
>> > branches are simply not in a releaseable state, or they have latent
>> > blocker
>> > bugs due to a lack of testing. This is what we've been struggling with
>> > on
>> > both the 2.8.x and 3.0.0-x release lines.
>> >
>> > So, in the abstract, I'm +1 on having a published policy on release
>> > cadence
>> > and EOL. This information helps users.
>> >
>> > However, I don't think we're ready to actually execute on this policy
>> > for
>> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
>> > publishing a policy we don't follow is more confusing to users.
>> >
>> > My 2c,
>> > Andrew
>> >
>> >
>> >
>> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal
>> > <aa...@hortonworks.com>
>> > wrote:
>> >
>> >> The ASF release policy says releases may not be vetoed [1] so the EOL
>> >> policy sounds unenforceable. Not sure a release cadence is enforceable
>> >> either since Release Managers are volunteers.
>> >>
>> >> 1. https://www.apache.org/dev/release.html#approving-a-release
>> >>
>> >>
>> >>
>> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>> >>
>> >> +1 on Sangjin's proposal -
>> >> "A minor release line is end-of-lifed 2 years after it is released
>> >> or
>> >> there
>> >> are 2 newer minor releases, whichever is sooner. The community
>> >> reserves the
>> >> right to extend or shorten the life of a release line if there is a
>> >> good
>> >> reason to do so."
>> >>
>> >> I also noticed Karthik bring up some new proposals - some of them
>> >> looks interesting to me and I have some ideas as well. Karthik, can you
>> >> bring it out in a separated discussion threads so that we can discuss
>> >> from
>> >> there?
>> >>
>> >> About Chris Trezzo's question about definition of EOL of hadoop
>> >> release, I think potentially changes could be:
>> >> 1. For users of Apache hadoop, they would expect to upgrade to a
>> >> new
>> >> minor/major releases after EOL of their current release because there
>> >> is no
>> >> guarantee of new maintenance release.
>> >>
>> >> 2. For release effort, apache law claim that committer can
>> >> volunteer
>> >> RM for any release. With this release EOL proposal passes and written
>> >> into
>> >> hadoop bylaw, anyone want to call for a release which is EOL then
>> >> she/he
>> >> have to provide a good reason to community and get voted before to
>> >> start
>> >> release effort. We don't want to waste community time/resource to
>> >> verify/vote a narrow interested release.
>> >>
>> >> 3. About committer's responsibility, I think the bottom line is
>> >> committer should commit patch contributor's target release and her/his
>> >> own
>> >> interest release which I conservatively agree with Allen's point that
>> >> this
>> >> vote doesn't change anything. But if a committer want to take care more
>> >> interest from the whole community like most committers are doing today,
>> >> he/she should understand which branches can benefit more people and
>> >> could
>> >> skip some EOL release branches for backport effort.
>> >>
>> >> About major release EOL, this could be more complicated and I think
>> >> we
>> >> should discuss separately.
>> >>
>> >> Thanks,
>> >>
>> >> Junping
>> >> ________________________________________
>> >> From: Allen Wittenauer <aw...@effectivemachines.com>
>> >> Sent: Wednesday, January 18, 2017 3:30 PM
>> >> To: Chris Trezzo
>> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
>> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> >> Subject: Re: [VOTE] Release cadence and EOL
>> >>
>> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
>> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Chris Douglas <cd...@apache.org>.
On Fri, Jan 20, 2017 at 2:50 PM, Sangjin Lee <sj...@apache.org> wrote:
> The security patch for the 2.6.x line is a case in point. Without any
> guideline, we would start with "What should we do for 2.6.x? Should we
> continue to patch it?" With this guideline, the baseline is already "it's
> been 2 years since 2.6.0 is released and we should consider stopping
> releasing from 2.6.x and encourage users to upgrade to 2.7.x."
Unless it falls under the "good reason" clause. To invent an example,
if 3.6.x were within the two year/minor release window, but 3.5.x was
more widely deployed/stable, then we'd use this escape hatch to patch
3.5.x and likely just violate our policy on 3.6.x (when the
implementation cost is high). How do we "force" a fix to 3.6.x?
We can't actually compel work from people. Even when we can point to a
prior consensus, someone needs to be motivated to actually complete
that task. That's the rub: this proposal doesn't only allow us to stop
working on old code, it also promises that we'll work on code we want
to abandon.
Pointing to a bylaw, and telling a contributor they "must" support a
branch/release isn't going to result in shorter discussions, either.
In the preceding hypothetical, if someone wants a fix in the 3.6 line,
they either need to convince others that it's important or they need
to do the work themselves.
> Actually the decision on security issues is a pretty strong indicator of our
> desire for EOL. If we say we do not want to patch that line for security
> vulnerability, then there would be even *less* rationale for fixing any
> other issue on that line. So the decision to stop backporting security
> patches is a sufficient indication of EOL in my mind.
Agreed. If we're not backporting security patches to a branch, then we
need to release a CVE, file a JIRA, and move on. If someone wants to
fix it and roll an RC for that release line, it lives. Otherwise it
dies as people move to later versions (unpatched security flaws are
motivating). A branch is EOL when we stop releasing from it. Two years
or two minor releases is a good heuristic based on recent history, but
overfitting policy to experience doesn't seem to buy us anything.
I'm all for spending less time discussing release criteria, but if
it's sufficient to observe which release lines are getting updates and
label them accordingly, that's cheaper to implement than a curated set
of constraints. -C
>> We can still embargo security flaws if someone asks (to give them time
>> time to implement a fix and call a vote). If there's nothing else in
>> the release, then we're effectively announcing it. In those cases, we
>> call a vote on private@ (cc: security@). -C
>>
>>
>> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> > I don't think the motivation here is vendor play or taking away power
>> > from
>> > committers. Having a regular release cadence helps our users understand
>> > when a feature will ship so they can plan their upgrades. Having an EOL
>> > policy and a minimum support period helps users choose a release line,
>> > and
>> > understand when they will need to upgrade.
>> >
>> > In the earlier thread, we discussed how these are not rules, but
>> > guidelines. There's a lot of flexibility if someone wants to keep
>> > maintaining a release line (particularly if they are willing to do the
>> > backporting work). More power to them; more releases are a good thing
>> > for
>> > the project.
>> >
>> > My main concern (which I raised on the earlier thread) is that without
>> > significant improvements to the release process and upstream integration
>> > testing, it's unlikely we'll actually ship more releases. Too often,
>> > branches are simply not in a releaseable state, or they have latent
>> > blocker
>> > bugs due to a lack of testing. This is what we've been struggling with
>> > on
>> > both the 2.8.x and 3.0.0-x release lines.
>> >
>> > So, in the abstract, I'm +1 on having a published policy on release
>> > cadence
>> > and EOL. This information helps users.
>> >
>> > However, I don't think we're ready to actually execute on this policy
>> > for
>> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
>> > publishing a policy we don't follow is more confusing to users.
>> >
>> > My 2c,
>> > Andrew
>> >
>> >
>> >
>> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal
>> > <aa...@hortonworks.com>
>> > wrote:
>> >
>> >> The ASF release policy says releases may not be vetoed [1] so the EOL
>> >> policy sounds unenforceable. Not sure a release cadence is enforceable
>> >> either since Release Managers are volunteers.
>> >>
>> >> 1. https://www.apache.org/dev/release.html#approving-a-release
>> >>
>> >>
>> >>
>> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>> >>
>> >> +1 on Sangjin's proposal -
>> >> "A minor release line is end-of-lifed 2 years after it is released
>> >> or
>> >> there
>> >> are 2 newer minor releases, whichever is sooner. The community
>> >> reserves the
>> >> right to extend or shorten the life of a release line if there is a
>> >> good
>> >> reason to do so."
>> >>
>> >> I also noticed Karthik bring up some new proposals - some of them
>> >> looks interesting to me and I have some ideas as well. Karthik, can you
>> >> bring it out in a separated discussion threads so that we can discuss
>> >> from
>> >> there?
>> >>
>> >> About Chris Trezzo's question about definition of EOL of hadoop
>> >> release, I think potentially changes could be:
>> >> 1. For users of Apache hadoop, they would expect to upgrade to a
>> >> new
>> >> minor/major releases after EOL of their current release because there
>> >> is no
>> >> guarantee of new maintenance release.
>> >>
>> >> 2. For release effort, apache law claim that committer can
>> >> volunteer
>> >> RM for any release. With this release EOL proposal passes and written
>> >> into
>> >> hadoop bylaw, anyone want to call for a release which is EOL then
>> >> she/he
>> >> have to provide a good reason to community and get voted before to
>> >> start
>> >> release effort. We don't want to waste community time/resource to
>> >> verify/vote a narrow interested release.
>> >>
>> >> 3. About committer's responsibility, I think the bottom line is
>> >> committer should commit patch contributor's target release and her/his
>> >> own
>> >> interest release which I conservatively agree with Allen's point that
>> >> this
>> >> vote doesn't change anything. But if a committer want to take care more
>> >> interest from the whole community like most committers are doing today,
>> >> he/she should understand which branches can benefit more people and
>> >> could
>> >> skip some EOL release branches for backport effort.
>> >>
>> >> About major release EOL, this could be more complicated and I think
>> >> we
>> >> should discuss separately.
>> >>
>> >> Thanks,
>> >>
>> >> Junping
>> >> ________________________________________
>> >> From: Allen Wittenauer <aw...@effectivemachines.com>
>> >> Sent: Wednesday, January 18, 2017 3:30 PM
>> >> To: Chris Trezzo
>> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
>> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> >> Subject: Re: [VOTE] Release cadence and EOL
>> >>
>> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
>> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Chris Douglas <cd...@apache.org>.
On Fri, Jan 20, 2017 at 2:50 PM, Sangjin Lee <sj...@apache.org> wrote:
> The security patch for the 2.6.x line is a case in point. Without any
> guideline, we would start with "What should we do for 2.6.x? Should we
> continue to patch it?" With this guideline, the baseline is already "it's
> been 2 years since 2.6.0 is released and we should consider stopping
> releasing from 2.6.x and encourage users to upgrade to 2.7.x."
Unless it falls under the "good reason" clause. To invent an example,
if 3.6.x were within the two year/minor release window, but 3.5.x was
more widely deployed/stable, then we'd use this escape hatch to patch
3.5.x and likely just violate our policy on 3.6.x (when the
implementation cost is high). How do we "force" a fix to 3.6.x?
We can't actually compel work from people. Even when we can point to a
prior consensus, someone needs to be motivated to actually complete
that task. That's the rub: this proposal doesn't only allow us to stop
working on old code, it also promises that we'll work on code we want
to abandon.
Pointing to a bylaw, and telling a contributor they "must" support a
branch/release isn't going to result in shorter discussions, either.
In the preceding hypothetical, if someone wants a fix in the 3.6 line,
they either need to convince others that it's important or they need
to do the work themselves.
> Actually the decision on security issues is a pretty strong indicator of our
> desire for EOL. If we say we do not want to patch that line for security
> vulnerability, then there would be even *less* rationale for fixing any
> other issue on that line. So the decision to stop backporting security
> patches is a sufficient indication of EOL in my mind.
Agreed. If we're not backporting security patches to a branch, then we
need to release a CVE, file a JIRA, and move on. If someone wants to
fix it and roll an RC for that release line, it lives. Otherwise it
dies as people move to later versions (unpatched security flaws are
motivating). A branch is EOL when we stop releasing from it. Two years
or two minor releases is a good heuristic based on recent history, but
overfitting policy to experience doesn't seem to buy us anything.
I'm all for spending less time discussing release criteria, but if
it's sufficient to observe which release lines are getting updates and
label them accordingly, that's cheaper to implement than a curated set
of constraints. -C
>> We can still embargo security flaws if someone asks (to give them time
>> time to implement a fix and call a vote). If there's nothing else in
>> the release, then we're effectively announcing it. In those cases, we
>> call a vote on private@ (cc: security@). -C
>>
>>
>> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> > I don't think the motivation here is vendor play or taking away power
>> > from
>> > committers. Having a regular release cadence helps our users understand
>> > when a feature will ship so they can plan their upgrades. Having an EOL
>> > policy and a minimum support period helps users choose a release line,
>> > and
>> > understand when they will need to upgrade.
>> >
>> > In the earlier thread, we discussed how these are not rules, but
>> > guidelines. There's a lot of flexibility if someone wants to keep
>> > maintaining a release line (particularly if they are willing to do the
>> > backporting work). More power to them; more releases are a good thing
>> > for
>> > the project.
>> >
>> > My main concern (which I raised on the earlier thread) is that without
>> > significant improvements to the release process and upstream integration
>> > testing, it's unlikely we'll actually ship more releases. Too often,
>> > branches are simply not in a releaseable state, or they have latent
>> > blocker
>> > bugs due to a lack of testing. This is what we've been struggling with
>> > on
>> > both the 2.8.x and 3.0.0-x release lines.
>> >
>> > So, in the abstract, I'm +1 on having a published policy on release
>> > cadence
>> > and EOL. This information helps users.
>> >
>> > However, I don't think we're ready to actually execute on this policy
>> > for
>> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
>> > publishing a policy we don't follow is more confusing to users.
>> >
>> > My 2c,
>> > Andrew
>> >
>> >
>> >
>> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal
>> > <aa...@hortonworks.com>
>> > wrote:
>> >
>> >> The ASF release policy says releases may not be vetoed [1] so the EOL
>> >> policy sounds unenforceable. Not sure a release cadence is enforceable
>> >> either since Release Managers are volunteers.
>> >>
>> >> 1. https://www.apache.org/dev/release.html#approving-a-release
>> >>
>> >>
>> >>
>> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>> >>
>> >> +1 on Sangjin's proposal -
>> >> "A minor release line is end-of-lifed 2 years after it is released
>> >> or
>> >> there
>> >> are 2 newer minor releases, whichever is sooner. The community
>> >> reserves the
>> >> right to extend or shorten the life of a release line if there is a
>> >> good
>> >> reason to do so."
>> >>
>> >> I also noticed Karthik bring up some new proposals - some of them
>> >> looks interesting to me and I have some ideas as well. Karthik, can you
>> >> bring it out in a separated discussion threads so that we can discuss
>> >> from
>> >> there?
>> >>
>> >> About Chris Trezzo's question about definition of EOL of hadoop
>> >> release, I think potentially changes could be:
>> >> 1. For users of Apache hadoop, they would expect to upgrade to a
>> >> new
>> >> minor/major releases after EOL of their current release because there
>> >> is no
>> >> guarantee of new maintenance release.
>> >>
>> >> 2. For release effort, apache law claim that committer can
>> >> volunteer
>> >> RM for any release. With this release EOL proposal passes and written
>> >> into
>> >> hadoop bylaw, anyone want to call for a release which is EOL then
>> >> she/he
>> >> have to provide a good reason to community and get voted before to
>> >> start
>> >> release effort. We don't want to waste community time/resource to
>> >> verify/vote a narrow interested release.
>> >>
>> >> 3. About committer's responsibility, I think the bottom line is
>> >> committer should commit patch contributor's target release and her/his
>> >> own
>> >> interest release which I conservatively agree with Allen's point that
>> >> this
>> >> vote doesn't change anything. But if a committer want to take care more
>> >> interest from the whole community like most committers are doing today,
>> >> he/she should understand which branches can benefit more people and
>> >> could
>> >> skip some EOL release branches for backport effort.
>> >>
>> >> About major release EOL, this could be more complicated and I think
>> >> we
>> >> should discuss separately.
>> >>
>> >> Thanks,
>> >>
>> >> Junping
>> >> ________________________________________
>> >> From: Allen Wittenauer <aw...@effectivemachines.com>
>> >> Sent: Wednesday, January 18, 2017 3:30 PM
>> >> To: Chris Trezzo
>> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
>> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> >> Subject: Re: [VOTE] Release cadence and EOL
>> >>
>> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
>> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Chris Douglas <cd...@apache.org>.
On Fri, Jan 20, 2017 at 2:50 PM, Sangjin Lee <sj...@apache.org> wrote:
> The security patch for the 2.6.x line is a case in point. Without any
> guideline, we would start with "What should we do for 2.6.x? Should we
> continue to patch it?" With this guideline, the baseline is already "it's
> been 2 years since 2.6.0 is released and we should consider stopping
> releasing from 2.6.x and encourage users to upgrade to 2.7.x."
Unless it falls under the "good reason" clause. To invent an example,
if 3.6.x were within the two year/minor release window, but 3.5.x was
more widely deployed/stable, then we'd use this escape hatch to patch
3.5.x and likely just violate our policy on 3.6.x (when the
implementation cost is high). How do we "force" a fix to 3.6.x?
We can't actually compel work from people. Even when we can point to a
prior consensus, someone needs to be motivated to actually complete
that task. That's the rub: this proposal doesn't only allow us to stop
working on old code, it also promises that we'll work on code we want
to abandon.
Pointing to a bylaw, and telling a contributor they "must" support a
branch/release isn't going to result in shorter discussions, either.
In the preceding hypothetical, if someone wants a fix in the 3.6 line,
they either need to convince others that it's important or they need
to do the work themselves.
> Actually the decision on security issues is a pretty strong indicator of our
> desire for EOL. If we say we do not want to patch that line for security
> vulnerability, then there would be even *less* rationale for fixing any
> other issue on that line. So the decision to stop backporting security
> patches is a sufficient indication of EOL in my mind.
Agreed. If we're not backporting security patches to a branch, then we
need to release a CVE, file a JIRA, and move on. If someone wants to
fix it and roll an RC for that release line, it lives. Otherwise it
dies as people move to later versions (unpatched security flaws are
motivating). A branch is EOL when we stop releasing from it. Two years
or two minor releases is a good heuristic based on recent history, but
overfitting policy to experience doesn't seem to buy us anything.
I'm all for spending less time discussing release criteria, but if
it's sufficient to observe which release lines are getting updates and
label them accordingly, that's cheaper to implement than a curated set
of constraints. -C
>> We can still embargo security flaws if someone asks (to give them time
>> time to implement a fix and call a vote). If there's nothing else in
>> the release, then we're effectively announcing it. In those cases, we
>> call a vote on private@ (cc: security@). -C
>>
>>
>> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
>> wrote:
>> > I don't think the motivation here is vendor play or taking away power
>> > from
>> > committers. Having a regular release cadence helps our users understand
>> > when a feature will ship so they can plan their upgrades. Having an EOL
>> > policy and a minimum support period helps users choose a release line,
>> > and
>> > understand when they will need to upgrade.
>> >
>> > In the earlier thread, we discussed how these are not rules, but
>> > guidelines. There's a lot of flexibility if someone wants to keep
>> > maintaining a release line (particularly if they are willing to do the
>> > backporting work). More power to them; more releases are a good thing
>> > for
>> > the project.
>> >
>> > My main concern (which I raised on the earlier thread) is that without
>> > significant improvements to the release process and upstream integration
>> > testing, it's unlikely we'll actually ship more releases. Too often,
>> > branches are simply not in a releaseable state, or they have latent
>> > blocker
>> > bugs due to a lack of testing. This is what we've been struggling with
>> > on
>> > both the 2.8.x and 3.0.0-x release lines.
>> >
>> > So, in the abstract, I'm +1 on having a published policy on release
>> > cadence
>> > and EOL. This information helps users.
>> >
>> > However, I don't think we're ready to actually execute on this policy
>> > for
>> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
>> > publishing a policy we don't follow is more confusing to users.
>> >
>> > My 2c,
>> > Andrew
>> >
>> >
>> >
>> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal
>> > <aa...@hortonworks.com>
>> > wrote:
>> >
>> >> The ASF release policy says releases may not be vetoed [1] so the EOL
>> >> policy sounds unenforceable. Not sure a release cadence is enforceable
>> >> either since Release Managers are volunteers.
>> >>
>> >> 1. https://www.apache.org/dev/release.html#approving-a-release
>> >>
>> >>
>> >>
>> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>> >>
>> >> +1 on Sangjin's proposal -
>> >> "A minor release line is end-of-lifed 2 years after it is released
>> >> or
>> >> there
>> >> are 2 newer minor releases, whichever is sooner. The community
>> >> reserves the
>> >> right to extend or shorten the life of a release line if there is a
>> >> good
>> >> reason to do so."
>> >>
>> >> I also noticed Karthik bring up some new proposals - some of them
>> >> looks interesting to me and I have some ideas as well. Karthik, can you
>> >> bring it out in a separated discussion threads so that we can discuss
>> >> from
>> >> there?
>> >>
>> >> About Chris Trezzo's question about definition of EOL of hadoop
>> >> release, I think potentially changes could be:
>> >> 1. For users of Apache hadoop, they would expect to upgrade to a
>> >> new
>> >> minor/major releases after EOL of their current release because there
>> >> is no
>> >> guarantee of new maintenance release.
>> >>
>> >> 2. For release effort, apache law claim that committer can
>> >> volunteer
>> >> RM for any release. With this release EOL proposal passes and written
>> >> into
>> >> hadoop bylaw, anyone want to call for a release which is EOL then
>> >> she/he
>> >> have to provide a good reason to community and get voted before to
>> >> start
>> >> release effort. We don't want to waste community time/resource to
>> >> verify/vote a narrow interested release.
>> >>
>> >> 3. About committer's responsibility, I think the bottom line is
>> >> committer should commit patch contributor's target release and her/his
>> >> own
>> >> interest release which I conservatively agree with Allen's point that
>> >> this
>> >> vote doesn't change anything. But if a committer want to take care more
>> >> interest from the whole community like most committers are doing today,
>> >> he/she should understand which branches can benefit more people and
>> >> could
>> >> skip some EOL release branches for backport effort.
>> >>
>> >> About major release EOL, this could be more complicated and I think
>> >> we
>> >> should discuss separately.
>> >>
>> >> Thanks,
>> >>
>> >> Junping
>> >> ________________________________________
>> >> From: Allen Wittenauer <aw...@effectivemachines.com>
>> >> Sent: Wednesday, January 18, 2017 3:30 PM
>> >> To: Chris Trezzo
>> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
>> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> >> Subject: Re: [VOTE] Release cadence and EOL
>> >>
>> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
>> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks for great feedback thus far.
I agree with some that this is more of a guideline than a policy. I also
agree to some extent that this is not very enforceable given the current
practice.
I do differ, though, on whether there is value in something like this if it
is not completely enforceable. I don't think it's such a binary situation,
and do think there is a plenty of middle ground where a good guideline can
save us time and help us a great deal.
If we view this more as a guideline (or a baseline if you will), this can
act as a reference point for discussion for setting up releases as well as
making decisions on stopping maintenance releases. Today, all of these
discussions invariably have to start from scratch with only past
experiences as a guide. We end up spending a decent amount of time just to
get to a common understanding. If we have a baseline to operate from, at
least we can considerably shorten that discussion and be a little more
productive and consistent as a community. I see value in that.
The security patch for the 2.6.x line is a case in point. Without any
guideline, we would start with "What should we do for 2.6.x? Should we
continue to patch it?" With this guideline, the baseline is already "it's
been 2 years since 2.6.0 is released and we should consider stopping
releasing from 2.6.x and encourage users to upgrade to 2.7.x."
What do you think?
On Thu, Jan 19, 2017 at 7:02 PM, Chris Douglas <cd...@apache.org> wrote:
> Sorry, I'd missed the end of the EOL discussion thread.
>
> As several people have pointed out, this is unenforceable. The release
> dates on the front page are a decent signal for liveness... do we need
> something more formal? All these hypothetical situations would be
> decided with more context. The "good reason" clause allows revive a
> release line if two "live" branches straddle a dud, so this proposal
> only commits us to maintain our mistakes. For two years? As Andrew
> points out, while this heuristic usually holds, we're not set up to
> enforce it.
>
> We may want to have an informal policy for security issues, since
> there are known holes in 2.6.x and earlier that aren't going to be
> patched. We need to issue CVEs for those. A policy would simplify
> tracking (e.g., announce vulnerabilities no more than a month after a
> fix is available in a later release), so we don't wait indefinitely to
> announce. Additionally, creating a JIRA and flagging the release on
> the download page would be ample warning.
>
Actually the decision on security issues is a pretty strong indicator of
our desire for EOL. If we say we do not want to patch that line for
security vulnerability, then there would be even *less* rationale for
fixing any other issue on that line. So the decision to stop backporting
security patches is a sufficient indication of EOL in my mind.
>
> We can still embargo security flaws if someone asks (to give them time
> time to implement a fix and call a vote). If there's nothing else in
> the release, then we're effectively announcing it. In those cases, we
> call a vote on private@ (cc: security@). -C
>
>
> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I don't think the motivation here is vendor play or taking away power
> from
> > committers. Having a regular release cadence helps our users understand
> > when a feature will ship so they can plan their upgrades. Having an EOL
> > policy and a minimum support period helps users choose a release line,
> and
> > understand when they will need to upgrade.
> >
> > In the earlier thread, we discussed how these are not rules, but
> > guidelines. There's a lot of flexibility if someone wants to keep
> > maintaining a release line (particularly if they are willing to do the
> > backporting work). More power to them; more releases are a good thing for
> > the project.
> >
> > My main concern (which I raised on the earlier thread) is that without
> > significant improvements to the release process and upstream integration
> > testing, it's unlikely we'll actually ship more releases. Too often,
> > branches are simply not in a releaseable state, or they have latent
> blocker
> > bugs due to a lack of testing. This is what we've been struggling with on
> > both the 2.8.x and 3.0.0-x release lines.
> >
> > So, in the abstract, I'm +1 on having a published policy on release
> cadence
> > and EOL. This information helps users.
> >
> > However, I don't think we're ready to actually execute on this policy for
> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
> > publishing a policy we don't follow is more confusing to users.
> >
> > My 2c,
> > Andrew
> >
> >
> >
> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <
> aagarwal@hortonworks.com>
> > wrote:
> >
> >> The ASF release policy says releases may not be vetoed [1] so the EOL
> >> policy sounds unenforceable. Not sure a release cadence is enforceable
> >> either since Release Managers are volunteers.
> >>
> >> 1. https://www.apache.org/dev/release.html#approving-a-release
> >>
> >>
> >>
> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
> >>
> >> +1 on Sangjin's proposal -
> >> "A minor release line is end-of-lifed 2 years after it is released
> or
> >> there
> >> are 2 newer minor releases, whichever is sooner. The community
> >> reserves the
> >> right to extend or shorten the life of a release line if there is a
> >> good
> >> reason to do so."
> >>
> >> I also noticed Karthik bring up some new proposals - some of them
> >> looks interesting to me and I have some ideas as well. Karthik, can you
> >> bring it out in a separated discussion threads so that we can discuss
> from
> >> there?
> >>
> >> About Chris Trezzo's question about definition of EOL of hadoop
> >> release, I think potentially changes could be:
> >> 1. For users of Apache hadoop, they would expect to upgrade to a new
> >> minor/major releases after EOL of their current release because there
> is no
> >> guarantee of new maintenance release.
> >>
> >> 2. For release effort, apache law claim that committer can volunteer
> >> RM for any release. With this release EOL proposal passes and written
> into
> >> hadoop bylaw, anyone want to call for a release which is EOL then she/he
> >> have to provide a good reason to community and get voted before to start
> >> release effort. We don't want to waste community time/resource to
> >> verify/vote a narrow interested release.
> >>
> >> 3. About committer's responsibility, I think the bottom line is
> >> committer should commit patch contributor's target release and her/his
> own
> >> interest release which I conservatively agree with Allen's point that
> this
> >> vote doesn't change anything. But if a committer want to take care more
> >> interest from the whole community like most committers are doing today,
> >> he/she should understand which branches can benefit more people and
> could
> >> skip some EOL release branches for backport effort.
> >>
> >> About major release EOL, this could be more complicated and I think
> we
> >> should discuss separately.
> >>
> >> Thanks,
> >>
> >> Junping
> >> ________________________________________
> >> From: Allen Wittenauer <aw...@effectivemachines.com>
> >> Sent: Wednesday, January 18, 2017 3:30 PM
> >> To: Chris Trezzo
> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> >> Subject: Re: [VOTE] Release cadence and EOL
> >>
> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >>
> >>
> >> ------------------------------------------------------------
> ---------
> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >>
> >>
> >>
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks for great feedback thus far.
I agree with some that this is more of a guideline than a policy. I also
agree to some extent that this is not very enforceable given the current
practice.
I do differ, though, on whether there is value in something like this if it
is not completely enforceable. I don't think it's such a binary situation,
and do think there is a plenty of middle ground where a good guideline can
save us time and help us a great deal.
If we view this more as a guideline (or a baseline if you will), this can
act as a reference point for discussion for setting up releases as well as
making decisions on stopping maintenance releases. Today, all of these
discussions invariably have to start from scratch with only past
experiences as a guide. We end up spending a decent amount of time just to
get to a common understanding. If we have a baseline to operate from, at
least we can considerably shorten that discussion and be a little more
productive and consistent as a community. I see value in that.
The security patch for the 2.6.x line is a case in point. Without any
guideline, we would start with "What should we do for 2.6.x? Should we
continue to patch it?" With this guideline, the baseline is already "it's
been 2 years since 2.6.0 is released and we should consider stopping
releasing from 2.6.x and encourage users to upgrade to 2.7.x."
What do you think?
On Thu, Jan 19, 2017 at 7:02 PM, Chris Douglas <cd...@apache.org> wrote:
> Sorry, I'd missed the end of the EOL discussion thread.
>
> As several people have pointed out, this is unenforceable. The release
> dates on the front page are a decent signal for liveness... do we need
> something more formal? All these hypothetical situations would be
> decided with more context. The "good reason" clause allows revive a
> release line if two "live" branches straddle a dud, so this proposal
> only commits us to maintain our mistakes. For two years? As Andrew
> points out, while this heuristic usually holds, we're not set up to
> enforce it.
>
> We may want to have an informal policy for security issues, since
> there are known holes in 2.6.x and earlier that aren't going to be
> patched. We need to issue CVEs for those. A policy would simplify
> tracking (e.g., announce vulnerabilities no more than a month after a
> fix is available in a later release), so we don't wait indefinitely to
> announce. Additionally, creating a JIRA and flagging the release on
> the download page would be ample warning.
>
Actually the decision on security issues is a pretty strong indicator of
our desire for EOL. If we say we do not want to patch that line for
security vulnerability, then there would be even *less* rationale for
fixing any other issue on that line. So the decision to stop backporting
security patches is a sufficient indication of EOL in my mind.
>
> We can still embargo security flaws if someone asks (to give them time
> time to implement a fix and call a vote). If there's nothing else in
> the release, then we're effectively announcing it. In those cases, we
> call a vote on private@ (cc: security@). -C
>
>
> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I don't think the motivation here is vendor play or taking away power
> from
> > committers. Having a regular release cadence helps our users understand
> > when a feature will ship so they can plan their upgrades. Having an EOL
> > policy and a minimum support period helps users choose a release line,
> and
> > understand when they will need to upgrade.
> >
> > In the earlier thread, we discussed how these are not rules, but
> > guidelines. There's a lot of flexibility if someone wants to keep
> > maintaining a release line (particularly if they are willing to do the
> > backporting work). More power to them; more releases are a good thing for
> > the project.
> >
> > My main concern (which I raised on the earlier thread) is that without
> > significant improvements to the release process and upstream integration
> > testing, it's unlikely we'll actually ship more releases. Too often,
> > branches are simply not in a releaseable state, or they have latent
> blocker
> > bugs due to a lack of testing. This is what we've been struggling with on
> > both the 2.8.x and 3.0.0-x release lines.
> >
> > So, in the abstract, I'm +1 on having a published policy on release
> cadence
> > and EOL. This information helps users.
> >
> > However, I don't think we're ready to actually execute on this policy for
> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
> > publishing a policy we don't follow is more confusing to users.
> >
> > My 2c,
> > Andrew
> >
> >
> >
> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <
> aagarwal@hortonworks.com>
> > wrote:
> >
> >> The ASF release policy says releases may not be vetoed [1] so the EOL
> >> policy sounds unenforceable. Not sure a release cadence is enforceable
> >> either since Release Managers are volunteers.
> >>
> >> 1. https://www.apache.org/dev/release.html#approving-a-release
> >>
> >>
> >>
> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
> >>
> >> +1 on Sangjin's proposal -
> >> "A minor release line is end-of-lifed 2 years after it is released
> or
> >> there
> >> are 2 newer minor releases, whichever is sooner. The community
> >> reserves the
> >> right to extend or shorten the life of a release line if there is a
> >> good
> >> reason to do so."
> >>
> >> I also noticed Karthik bring up some new proposals - some of them
> >> looks interesting to me and I have some ideas as well. Karthik, can you
> >> bring it out in a separated discussion threads so that we can discuss
> from
> >> there?
> >>
> >> About Chris Trezzo's question about definition of EOL of hadoop
> >> release, I think potentially changes could be:
> >> 1. For users of Apache hadoop, they would expect to upgrade to a new
> >> minor/major releases after EOL of their current release because there
> is no
> >> guarantee of new maintenance release.
> >>
> >> 2. For release effort, apache law claim that committer can volunteer
> >> RM for any release. With this release EOL proposal passes and written
> into
> >> hadoop bylaw, anyone want to call for a release which is EOL then she/he
> >> have to provide a good reason to community and get voted before to start
> >> release effort. We don't want to waste community time/resource to
> >> verify/vote a narrow interested release.
> >>
> >> 3. About committer's responsibility, I think the bottom line is
> >> committer should commit patch contributor's target release and her/his
> own
> >> interest release which I conservatively agree with Allen's point that
> this
> >> vote doesn't change anything. But if a committer want to take care more
> >> interest from the whole community like most committers are doing today,
> >> he/she should understand which branches can benefit more people and
> could
> >> skip some EOL release branches for backport effort.
> >>
> >> About major release EOL, this could be more complicated and I think
> we
> >> should discuss separately.
> >>
> >> Thanks,
> >>
> >> Junping
> >> ________________________________________
> >> From: Allen Wittenauer <aw...@effectivemachines.com>
> >> Sent: Wednesday, January 18, 2017 3:30 PM
> >> To: Chris Trezzo
> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> >> Subject: Re: [VOTE] Release cadence and EOL
> >>
> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >>
> >>
> >> ------------------------------------------------------------
> ---------
> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >>
> >>
> >>
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks for great feedback thus far.
I agree with some that this is more of a guideline than a policy. I also
agree to some extent that this is not very enforceable given the current
practice.
I do differ, though, on whether there is value in something like this if it
is not completely enforceable. I don't think it's such a binary situation,
and do think there is a plenty of middle ground where a good guideline can
save us time and help us a great deal.
If we view this more as a guideline (or a baseline if you will), this can
act as a reference point for discussion for setting up releases as well as
making decisions on stopping maintenance releases. Today, all of these
discussions invariably have to start from scratch with only past
experiences as a guide. We end up spending a decent amount of time just to
get to a common understanding. If we have a baseline to operate from, at
least we can considerably shorten that discussion and be a little more
productive and consistent as a community. I see value in that.
The security patch for the 2.6.x line is a case in point. Without any
guideline, we would start with "What should we do for 2.6.x? Should we
continue to patch it?" With this guideline, the baseline is already "it's
been 2 years since 2.6.0 is released and we should consider stopping
releasing from 2.6.x and encourage users to upgrade to 2.7.x."
What do you think?
On Thu, Jan 19, 2017 at 7:02 PM, Chris Douglas <cd...@apache.org> wrote:
> Sorry, I'd missed the end of the EOL discussion thread.
>
> As several people have pointed out, this is unenforceable. The release
> dates on the front page are a decent signal for liveness... do we need
> something more formal? All these hypothetical situations would be
> decided with more context. The "good reason" clause allows revive a
> release line if two "live" branches straddle a dud, so this proposal
> only commits us to maintain our mistakes. For two years? As Andrew
> points out, while this heuristic usually holds, we're not set up to
> enforce it.
>
> We may want to have an informal policy for security issues, since
> there are known holes in 2.6.x and earlier that aren't going to be
> patched. We need to issue CVEs for those. A policy would simplify
> tracking (e.g., announce vulnerabilities no more than a month after a
> fix is available in a later release), so we don't wait indefinitely to
> announce. Additionally, creating a JIRA and flagging the release on
> the download page would be ample warning.
>
Actually the decision on security issues is a pretty strong indicator of
our desire for EOL. If we say we do not want to patch that line for
security vulnerability, then there would be even *less* rationale for
fixing any other issue on that line. So the decision to stop backporting
security patches is a sufficient indication of EOL in my mind.
>
> We can still embargo security flaws if someone asks (to give them time
> time to implement a fix and call a vote). If there's nothing else in
> the release, then we're effectively announcing it. In those cases, we
> call a vote on private@ (cc: security@). -C
>
>
> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I don't think the motivation here is vendor play or taking away power
> from
> > committers. Having a regular release cadence helps our users understand
> > when a feature will ship so they can plan their upgrades. Having an EOL
> > policy and a minimum support period helps users choose a release line,
> and
> > understand when they will need to upgrade.
> >
> > In the earlier thread, we discussed how these are not rules, but
> > guidelines. There's a lot of flexibility if someone wants to keep
> > maintaining a release line (particularly if they are willing to do the
> > backporting work). More power to them; more releases are a good thing for
> > the project.
> >
> > My main concern (which I raised on the earlier thread) is that without
> > significant improvements to the release process and upstream integration
> > testing, it's unlikely we'll actually ship more releases. Too often,
> > branches are simply not in a releaseable state, or they have latent
> blocker
> > bugs due to a lack of testing. This is what we've been struggling with on
> > both the 2.8.x and 3.0.0-x release lines.
> >
> > So, in the abstract, I'm +1 on having a published policy on release
> cadence
> > and EOL. This information helps users.
> >
> > However, I don't think we're ready to actually execute on this policy for
> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
> > publishing a policy we don't follow is more confusing to users.
> >
> > My 2c,
> > Andrew
> >
> >
> >
> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <
> aagarwal@hortonworks.com>
> > wrote:
> >
> >> The ASF release policy says releases may not be vetoed [1] so the EOL
> >> policy sounds unenforceable. Not sure a release cadence is enforceable
> >> either since Release Managers are volunteers.
> >>
> >> 1. https://www.apache.org/dev/release.html#approving-a-release
> >>
> >>
> >>
> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
> >>
> >> +1 on Sangjin's proposal -
> >> "A minor release line is end-of-lifed 2 years after it is released
> or
> >> there
> >> are 2 newer minor releases, whichever is sooner. The community
> >> reserves the
> >> right to extend or shorten the life of a release line if there is a
> >> good
> >> reason to do so."
> >>
> >> I also noticed Karthik bring up some new proposals - some of them
> >> looks interesting to me and I have some ideas as well. Karthik, can you
> >> bring it out in a separated discussion threads so that we can discuss
> from
> >> there?
> >>
> >> About Chris Trezzo's question about definition of EOL of hadoop
> >> release, I think potentially changes could be:
> >> 1. For users of Apache hadoop, they would expect to upgrade to a new
> >> minor/major releases after EOL of their current release because there
> is no
> >> guarantee of new maintenance release.
> >>
> >> 2. For release effort, apache law claim that committer can volunteer
> >> RM for any release. With this release EOL proposal passes and written
> into
> >> hadoop bylaw, anyone want to call for a release which is EOL then she/he
> >> have to provide a good reason to community and get voted before to start
> >> release effort. We don't want to waste community time/resource to
> >> verify/vote a narrow interested release.
> >>
> >> 3. About committer's responsibility, I think the bottom line is
> >> committer should commit patch contributor's target release and her/his
> own
> >> interest release which I conservatively agree with Allen's point that
> this
> >> vote doesn't change anything. But if a committer want to take care more
> >> interest from the whole community like most committers are doing today,
> >> he/she should understand which branches can benefit more people and
> could
> >> skip some EOL release branches for backport effort.
> >>
> >> About major release EOL, this could be more complicated and I think
> we
> >> should discuss separately.
> >>
> >> Thanks,
> >>
> >> Junping
> >> ________________________________________
> >> From: Allen Wittenauer <aw...@effectivemachines.com>
> >> Sent: Wednesday, January 18, 2017 3:30 PM
> >> To: Chris Trezzo
> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> >> Subject: Re: [VOTE] Release cadence and EOL
> >>
> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >>
> >>
> >> ------------------------------------------------------------
> ---------
> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >>
> >>
> >>
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks for great feedback thus far.
I agree with some that this is more of a guideline than a policy. I also
agree to some extent that this is not very enforceable given the current
practice.
I do differ, though, on whether there is value in something like this if it
is not completely enforceable. I don't think it's such a binary situation,
and do think there is a plenty of middle ground where a good guideline can
save us time and help us a great deal.
If we view this more as a guideline (or a baseline if you will), this can
act as a reference point for discussion for setting up releases as well as
making decisions on stopping maintenance releases. Today, all of these
discussions invariably have to start from scratch with only past
experiences as a guide. We end up spending a decent amount of time just to
get to a common understanding. If we have a baseline to operate from, at
least we can considerably shorten that discussion and be a little more
productive and consistent as a community. I see value in that.
The security patch for the 2.6.x line is a case in point. Without any
guideline, we would start with "What should we do for 2.6.x? Should we
continue to patch it?" With this guideline, the baseline is already "it's
been 2 years since 2.6.0 is released and we should consider stopping
releasing from 2.6.x and encourage users to upgrade to 2.7.x."
What do you think?
On Thu, Jan 19, 2017 at 7:02 PM, Chris Douglas <cd...@apache.org> wrote:
> Sorry, I'd missed the end of the EOL discussion thread.
>
> As several people have pointed out, this is unenforceable. The release
> dates on the front page are a decent signal for liveness... do we need
> something more formal? All these hypothetical situations would be
> decided with more context. The "good reason" clause allows revive a
> release line if two "live" branches straddle a dud, so this proposal
> only commits us to maintain our mistakes. For two years? As Andrew
> points out, while this heuristic usually holds, we're not set up to
> enforce it.
>
> We may want to have an informal policy for security issues, since
> there are known holes in 2.6.x and earlier that aren't going to be
> patched. We need to issue CVEs for those. A policy would simplify
> tracking (e.g., announce vulnerabilities no more than a month after a
> fix is available in a later release), so we don't wait indefinitely to
> announce. Additionally, creating a JIRA and flagging the release on
> the download page would be ample warning.
>
Actually the decision on security issues is a pretty strong indicator of
our desire for EOL. If we say we do not want to patch that line for
security vulnerability, then there would be even *less* rationale for
fixing any other issue on that line. So the decision to stop backporting
security patches is a sufficient indication of EOL in my mind.
>
> We can still embargo security flaws if someone asks (to give them time
> time to implement a fix and call a vote). If there's nothing else in
> the release, then we're effectively announcing it. In those cases, we
> call a vote on private@ (cc: security@). -C
>
>
> On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com>
> wrote:
> > I don't think the motivation here is vendor play or taking away power
> from
> > committers. Having a regular release cadence helps our users understand
> > when a feature will ship so they can plan their upgrades. Having an EOL
> > policy and a minimum support period helps users choose a release line,
> and
> > understand when they will need to upgrade.
> >
> > In the earlier thread, we discussed how these are not rules, but
> > guidelines. There's a lot of flexibility if someone wants to keep
> > maintaining a release line (particularly if they are willing to do the
> > backporting work). More power to them; more releases are a good thing for
> > the project.
> >
> > My main concern (which I raised on the earlier thread) is that without
> > significant improvements to the release process and upstream integration
> > testing, it's unlikely we'll actually ship more releases. Too often,
> > branches are simply not in a releaseable state, or they have latent
> blocker
> > bugs due to a lack of testing. This is what we've been struggling with on
> > both the 2.8.x and 3.0.0-x release lines.
> >
> > So, in the abstract, I'm +1 on having a published policy on release
> cadence
> > and EOL. This information helps users.
> >
> > However, I don't think we're ready to actually execute on this policy for
> > the above reasons. This leaves me ambivalent overall, perhaps -0 since
> > publishing a policy we don't follow is more confusing to users.
> >
> > My 2c,
> > Andrew
> >
> >
> >
> > On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <
> aagarwal@hortonworks.com>
> > wrote:
> >
> >> The ASF release policy says releases may not be vetoed [1] so the EOL
> >> policy sounds unenforceable. Not sure a release cadence is enforceable
> >> either since Release Managers are volunteers.
> >>
> >> 1. https://www.apache.org/dev/release.html#approving-a-release
> >>
> >>
> >>
> >> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
> >>
> >> +1 on Sangjin's proposal -
> >> "A minor release line is end-of-lifed 2 years after it is released
> or
> >> there
> >> are 2 newer minor releases, whichever is sooner. The community
> >> reserves the
> >> right to extend or shorten the life of a release line if there is a
> >> good
> >> reason to do so."
> >>
> >> I also noticed Karthik bring up some new proposals - some of them
> >> looks interesting to me and I have some ideas as well. Karthik, can you
> >> bring it out in a separated discussion threads so that we can discuss
> from
> >> there?
> >>
> >> About Chris Trezzo's question about definition of EOL of hadoop
> >> release, I think potentially changes could be:
> >> 1. For users of Apache hadoop, they would expect to upgrade to a new
> >> minor/major releases after EOL of their current release because there
> is no
> >> guarantee of new maintenance release.
> >>
> >> 2. For release effort, apache law claim that committer can volunteer
> >> RM for any release. With this release EOL proposal passes and written
> into
> >> hadoop bylaw, anyone want to call for a release which is EOL then she/he
> >> have to provide a good reason to community and get voted before to start
> >> release effort. We don't want to waste community time/resource to
> >> verify/vote a narrow interested release.
> >>
> >> 3. About committer's responsibility, I think the bottom line is
> >> committer should commit patch contributor's target release and her/his
> own
> >> interest release which I conservatively agree with Allen's point that
> this
> >> vote doesn't change anything. But if a committer want to take care more
> >> interest from the whole community like most committers are doing today,
> >> he/she should understand which branches can benefit more people and
> could
> >> skip some EOL release branches for backport effort.
> >>
> >> About major release EOL, this could be more complicated and I think
> we
> >> should discuss separately.
> >>
> >> Thanks,
> >>
> >> Junping
> >> ________________________________________
> >> From: Allen Wittenauer <aw...@effectivemachines.com>
> >> Sent: Wednesday, January 18, 2017 3:30 PM
> >> To: Chris Trezzo
> >> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> >> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> >> Subject: Re: [VOTE] Release cadence and EOL
> >>
> >> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
> >>
> >>
> >> ------------------------------------------------------------
> ---------
> >> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> >> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
> >>
> >>
> >>
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Chris Douglas <cd...@apache.org>.
Sorry, I'd missed the end of the EOL discussion thread.
As several people have pointed out, this is unenforceable. The release
dates on the front page are a decent signal for liveness... do we need
something more formal? All these hypothetical situations would be
decided with more context. The "good reason" clause allows revive a
release line if two "live" branches straddle a dud, so this proposal
only commits us to maintain our mistakes. For two years? As Andrew
points out, while this heuristic usually holds, we're not set up to
enforce it.
We may want to have an informal policy for security issues, since
there are known holes in 2.6.x and earlier that aren't going to be
patched. We need to issue CVEs for those. A policy would simplify
tracking (e.g., announce vulnerabilities no more than a month after a
fix is available in a later release), so we don't wait indefinitely to
announce. Additionally, creating a JIRA and flagging the release on
the download page would be ample warning.
We can still embargo security flaws if someone asks (to give them time
time to implement a fix and call a vote). If there's nothing else in
the release, then we're effectively announcing it. In those cases, we
call a vote on private@ (cc: security@). -C
On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com> wrote:
> I don't think the motivation here is vendor play or taking away power from
> committers. Having a regular release cadence helps our users understand
> when a feature will ship so they can plan their upgrades. Having an EOL
> policy and a minimum support period helps users choose a release line, and
> understand when they will need to upgrade.
>
> In the earlier thread, we discussed how these are not rules, but
> guidelines. There's a lot of flexibility if someone wants to keep
> maintaining a release line (particularly if they are willing to do the
> backporting work). More power to them; more releases are a good thing for
> the project.
>
> My main concern (which I raised on the earlier thread) is that without
> significant improvements to the release process and upstream integration
> testing, it's unlikely we'll actually ship more releases. Too often,
> branches are simply not in a releaseable state, or they have latent blocker
> bugs due to a lack of testing. This is what we've been struggling with on
> both the 2.8.x and 3.0.0-x release lines.
>
> So, in the abstract, I'm +1 on having a published policy on release cadence
> and EOL. This information helps users.
>
> However, I don't think we're ready to actually execute on this policy for
> the above reasons. This leaves me ambivalent overall, perhaps -0 since
> publishing a policy we don't follow is more confusing to users.
>
> My 2c,
> Andrew
>
>
>
> On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
>> The ASF release policy says releases may not be vetoed [1] so the EOL
>> policy sounds unenforceable. Not sure a release cadence is enforceable
>> either since Release Managers are volunteers.
>>
>> 1. https://www.apache.org/dev/release.html#approving-a-release
>>
>>
>>
>> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>>
>> +1 on Sangjin's proposal -
>> "A minor release line is end-of-lifed 2 years after it is released or
>> there
>> are 2 newer minor releases, whichever is sooner. The community
>> reserves the
>> right to extend or shorten the life of a release line if there is a
>> good
>> reason to do so."
>>
>> I also noticed Karthik bring up some new proposals - some of them
>> looks interesting to me and I have some ideas as well. Karthik, can you
>> bring it out in a separated discussion threads so that we can discuss from
>> there?
>>
>> About Chris Trezzo's question about definition of EOL of hadoop
>> release, I think potentially changes could be:
>> 1. For users of Apache hadoop, they would expect to upgrade to a new
>> minor/major releases after EOL of their current release because there is no
>> guarantee of new maintenance release.
>>
>> 2. For release effort, apache law claim that committer can volunteer
>> RM for any release. With this release EOL proposal passes and written into
>> hadoop bylaw, anyone want to call for a release which is EOL then she/he
>> have to provide a good reason to community and get voted before to start
>> release effort. We don't want to waste community time/resource to
>> verify/vote a narrow interested release.
>>
>> 3. About committer's responsibility, I think the bottom line is
>> committer should commit patch contributor's target release and her/his own
>> interest release which I conservatively agree with Allen's point that this
>> vote doesn't change anything. But if a committer want to take care more
>> interest from the whole community like most committers are doing today,
>> he/she should understand which branches can benefit more people and could
>> skip some EOL release branches for backport effort.
>>
>> About major release EOL, this could be more complicated and I think we
>> should discuss separately.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Allen Wittenauer <aw...@effectivemachines.com>
>> Sent: Wednesday, January 18, 2017 3:30 PM
>> To: Chris Trezzo
>> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
>> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release cadence and EOL
>>
>> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Chris Douglas <cd...@apache.org>.
Sorry, I'd missed the end of the EOL discussion thread.
As several people have pointed out, this is unenforceable. The release
dates on the front page are a decent signal for liveness... do we need
something more formal? All these hypothetical situations would be
decided with more context. The "good reason" clause allows revive a
release line if two "live" branches straddle a dud, so this proposal
only commits us to maintain our mistakes. For two years? As Andrew
points out, while this heuristic usually holds, we're not set up to
enforce it.
We may want to have an informal policy for security issues, since
there are known holes in 2.6.x and earlier that aren't going to be
patched. We need to issue CVEs for those. A policy would simplify
tracking (e.g., announce vulnerabilities no more than a month after a
fix is available in a later release), so we don't wait indefinitely to
announce. Additionally, creating a JIRA and flagging the release on
the download page would be ample warning.
We can still embargo security flaws if someone asks (to give them time
time to implement a fix and call a vote). If there's nothing else in
the release, then we're effectively announcing it. In those cases, we
call a vote on private@ (cc: security@). -C
On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com> wrote:
> I don't think the motivation here is vendor play or taking away power from
> committers. Having a regular release cadence helps our users understand
> when a feature will ship so they can plan their upgrades. Having an EOL
> policy and a minimum support period helps users choose a release line, and
> understand when they will need to upgrade.
>
> In the earlier thread, we discussed how these are not rules, but
> guidelines. There's a lot of flexibility if someone wants to keep
> maintaining a release line (particularly if they are willing to do the
> backporting work). More power to them; more releases are a good thing for
> the project.
>
> My main concern (which I raised on the earlier thread) is that without
> significant improvements to the release process and upstream integration
> testing, it's unlikely we'll actually ship more releases. Too often,
> branches are simply not in a releaseable state, or they have latent blocker
> bugs due to a lack of testing. This is what we've been struggling with on
> both the 2.8.x and 3.0.0-x release lines.
>
> So, in the abstract, I'm +1 on having a published policy on release cadence
> and EOL. This information helps users.
>
> However, I don't think we're ready to actually execute on this policy for
> the above reasons. This leaves me ambivalent overall, perhaps -0 since
> publishing a policy we don't follow is more confusing to users.
>
> My 2c,
> Andrew
>
>
>
> On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
>> The ASF release policy says releases may not be vetoed [1] so the EOL
>> policy sounds unenforceable. Not sure a release cadence is enforceable
>> either since Release Managers are volunteers.
>>
>> 1. https://www.apache.org/dev/release.html#approving-a-release
>>
>>
>>
>> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>>
>> +1 on Sangjin's proposal -
>> "A minor release line is end-of-lifed 2 years after it is released or
>> there
>> are 2 newer minor releases, whichever is sooner. The community
>> reserves the
>> right to extend or shorten the life of a release line if there is a
>> good
>> reason to do so."
>>
>> I also noticed Karthik bring up some new proposals - some of them
>> looks interesting to me and I have some ideas as well. Karthik, can you
>> bring it out in a separated discussion threads so that we can discuss from
>> there?
>>
>> About Chris Trezzo's question about definition of EOL of hadoop
>> release, I think potentially changes could be:
>> 1. For users of Apache hadoop, they would expect to upgrade to a new
>> minor/major releases after EOL of their current release because there is no
>> guarantee of new maintenance release.
>>
>> 2. For release effort, apache law claim that committer can volunteer
>> RM for any release. With this release EOL proposal passes and written into
>> hadoop bylaw, anyone want to call for a release which is EOL then she/he
>> have to provide a good reason to community and get voted before to start
>> release effort. We don't want to waste community time/resource to
>> verify/vote a narrow interested release.
>>
>> 3. About committer's responsibility, I think the bottom line is
>> committer should commit patch contributor's target release and her/his own
>> interest release which I conservatively agree with Allen's point that this
>> vote doesn't change anything. But if a committer want to take care more
>> interest from the whole community like most committers are doing today,
>> he/she should understand which branches can benefit more people and could
>> skip some EOL release branches for backport effort.
>>
>> About major release EOL, this could be more complicated and I think we
>> should discuss separately.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Allen Wittenauer <aw...@effectivemachines.com>
>> Sent: Wednesday, January 18, 2017 3:30 PM
>> To: Chris Trezzo
>> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
>> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release cadence and EOL
>>
>> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Chris Douglas <cd...@apache.org>.
Sorry, I'd missed the end of the EOL discussion thread.
As several people have pointed out, this is unenforceable. The release
dates on the front page are a decent signal for liveness... do we need
something more formal? All these hypothetical situations would be
decided with more context. The "good reason" clause allows revive a
release line if two "live" branches straddle a dud, so this proposal
only commits us to maintain our mistakes. For two years? As Andrew
points out, while this heuristic usually holds, we're not set up to
enforce it.
We may want to have an informal policy for security issues, since
there are known holes in 2.6.x and earlier that aren't going to be
patched. We need to issue CVEs for those. A policy would simplify
tracking (e.g., announce vulnerabilities no more than a month after a
fix is available in a later release), so we don't wait indefinitely to
announce. Additionally, creating a JIRA and flagging the release on
the download page would be ample warning.
We can still embargo security flaws if someone asks (to give them time
time to implement a fix and call a vote). If there's nothing else in
the release, then we're effectively announcing it. In those cases, we
call a vote on private@ (cc: security@). -C
On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com> wrote:
> I don't think the motivation here is vendor play or taking away power from
> committers. Having a regular release cadence helps our users understand
> when a feature will ship so they can plan their upgrades. Having an EOL
> policy and a minimum support period helps users choose a release line, and
> understand when they will need to upgrade.
>
> In the earlier thread, we discussed how these are not rules, but
> guidelines. There's a lot of flexibility if someone wants to keep
> maintaining a release line (particularly if they are willing to do the
> backporting work). More power to them; more releases are a good thing for
> the project.
>
> My main concern (which I raised on the earlier thread) is that without
> significant improvements to the release process and upstream integration
> testing, it's unlikely we'll actually ship more releases. Too often,
> branches are simply not in a releaseable state, or they have latent blocker
> bugs due to a lack of testing. This is what we've been struggling with on
> both the 2.8.x and 3.0.0-x release lines.
>
> So, in the abstract, I'm +1 on having a published policy on release cadence
> and EOL. This information helps users.
>
> However, I don't think we're ready to actually execute on this policy for
> the above reasons. This leaves me ambivalent overall, perhaps -0 since
> publishing a policy we don't follow is more confusing to users.
>
> My 2c,
> Andrew
>
>
>
> On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
>> The ASF release policy says releases may not be vetoed [1] so the EOL
>> policy sounds unenforceable. Not sure a release cadence is enforceable
>> either since Release Managers are volunteers.
>>
>> 1. https://www.apache.org/dev/release.html#approving-a-release
>>
>>
>>
>> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>>
>> +1 on Sangjin's proposal -
>> "A minor release line is end-of-lifed 2 years after it is released or
>> there
>> are 2 newer minor releases, whichever is sooner. The community
>> reserves the
>> right to extend or shorten the life of a release line if there is a
>> good
>> reason to do so."
>>
>> I also noticed Karthik bring up some new proposals - some of them
>> looks interesting to me and I have some ideas as well. Karthik, can you
>> bring it out in a separated discussion threads so that we can discuss from
>> there?
>>
>> About Chris Trezzo's question about definition of EOL of hadoop
>> release, I think potentially changes could be:
>> 1. For users of Apache hadoop, they would expect to upgrade to a new
>> minor/major releases after EOL of their current release because there is no
>> guarantee of new maintenance release.
>>
>> 2. For release effort, apache law claim that committer can volunteer
>> RM for any release. With this release EOL proposal passes and written into
>> hadoop bylaw, anyone want to call for a release which is EOL then she/he
>> have to provide a good reason to community and get voted before to start
>> release effort. We don't want to waste community time/resource to
>> verify/vote a narrow interested release.
>>
>> 3. About committer's responsibility, I think the bottom line is
>> committer should commit patch contributor's target release and her/his own
>> interest release which I conservatively agree with Allen's point that this
>> vote doesn't change anything. But if a committer want to take care more
>> interest from the whole community like most committers are doing today,
>> he/she should understand which branches can benefit more people and could
>> skip some EOL release branches for backport effort.
>>
>> About major release EOL, this could be more complicated and I think we
>> should discuss separately.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Allen Wittenauer <aw...@effectivemachines.com>
>> Sent: Wednesday, January 18, 2017 3:30 PM
>> To: Chris Trezzo
>> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
>> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release cadence and EOL
>>
>> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Chris Douglas <cd...@apache.org>.
Sorry, I'd missed the end of the EOL discussion thread.
As several people have pointed out, this is unenforceable. The release
dates on the front page are a decent signal for liveness... do we need
something more formal? All these hypothetical situations would be
decided with more context. The "good reason" clause allows revive a
release line if two "live" branches straddle a dud, so this proposal
only commits us to maintain our mistakes. For two years? As Andrew
points out, while this heuristic usually holds, we're not set up to
enforce it.
We may want to have an informal policy for security issues, since
there are known holes in 2.6.x and earlier that aren't going to be
patched. We need to issue CVEs for those. A policy would simplify
tracking (e.g., announce vulnerabilities no more than a month after a
fix is available in a later release), so we don't wait indefinitely to
announce. Additionally, creating a JIRA and flagging the release on
the download page would be ample warning.
We can still embargo security flaws if someone asks (to give them time
time to implement a fix and call a vote). If there's nothing else in
the release, then we're effectively announcing it. In those cases, we
call a vote on private@ (cc: security@). -C
On Thu, Jan 19, 2017 at 1:30 PM, Andrew Wang <an...@cloudera.com> wrote:
> I don't think the motivation here is vendor play or taking away power from
> committers. Having a regular release cadence helps our users understand
> when a feature will ship so they can plan their upgrades. Having an EOL
> policy and a minimum support period helps users choose a release line, and
> understand when they will need to upgrade.
>
> In the earlier thread, we discussed how these are not rules, but
> guidelines. There's a lot of flexibility if someone wants to keep
> maintaining a release line (particularly if they are willing to do the
> backporting work). More power to them; more releases are a good thing for
> the project.
>
> My main concern (which I raised on the earlier thread) is that without
> significant improvements to the release process and upstream integration
> testing, it's unlikely we'll actually ship more releases. Too often,
> branches are simply not in a releaseable state, or they have latent blocker
> bugs due to a lack of testing. This is what we've been struggling with on
> both the 2.8.x and 3.0.0-x release lines.
>
> So, in the abstract, I'm +1 on having a published policy on release cadence
> and EOL. This information helps users.
>
> However, I don't think we're ready to actually execute on this policy for
> the above reasons. This leaves me ambivalent overall, perhaps -0 since
> publishing a policy we don't follow is more confusing to users.
>
> My 2c,
> Andrew
>
>
>
> On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <aa...@hortonworks.com>
> wrote:
>
>> The ASF release policy says releases may not be vetoed [1] so the EOL
>> policy sounds unenforceable. Not sure a release cadence is enforceable
>> either since Release Managers are volunteers.
>>
>> 1. https://www.apache.org/dev/release.html#approving-a-release
>>
>>
>>
>> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>>
>> +1 on Sangjin's proposal -
>> "A minor release line is end-of-lifed 2 years after it is released or
>> there
>> are 2 newer minor releases, whichever is sooner. The community
>> reserves the
>> right to extend or shorten the life of a release line if there is a
>> good
>> reason to do so."
>>
>> I also noticed Karthik bring up some new proposals - some of them
>> looks interesting to me and I have some ideas as well. Karthik, can you
>> bring it out in a separated discussion threads so that we can discuss from
>> there?
>>
>> About Chris Trezzo's question about definition of EOL of hadoop
>> release, I think potentially changes could be:
>> 1. For users of Apache hadoop, they would expect to upgrade to a new
>> minor/major releases after EOL of their current release because there is no
>> guarantee of new maintenance release.
>>
>> 2. For release effort, apache law claim that committer can volunteer
>> RM for any release. With this release EOL proposal passes and written into
>> hadoop bylaw, anyone want to call for a release which is EOL then she/he
>> have to provide a good reason to community and get voted before to start
>> release effort. We don't want to waste community time/resource to
>> verify/vote a narrow interested release.
>>
>> 3. About committer's responsibility, I think the bottom line is
>> committer should commit patch contributor's target release and her/his own
>> interest release which I conservatively agree with Allen's point that this
>> vote doesn't change anything. But if a committer want to take care more
>> interest from the whole community like most committers are doing today,
>> he/she should understand which branches can benefit more people and could
>> skip some EOL release branches for backport effort.
>>
>> About major release EOL, this could be more complicated and I think we
>> should discuss separately.
>>
>> Thanks,
>>
>> Junping
>> ________________________________________
>> From: Allen Wittenauer <aw...@effectivemachines.com>
>> Sent: Wednesday, January 18, 2017 3:30 PM
>> To: Chris Trezzo
>> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
>> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release cadence and EOL
>>
>> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>>
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Andrew Wang <an...@cloudera.com>.
I don't think the motivation here is vendor play or taking away power from
committers. Having a regular release cadence helps our users understand
when a feature will ship so they can plan their upgrades. Having an EOL
policy and a minimum support period helps users choose a release line, and
understand when they will need to upgrade.
In the earlier thread, we discussed how these are not rules, but
guidelines. There's a lot of flexibility if someone wants to keep
maintaining a release line (particularly if they are willing to do the
backporting work). More power to them; more releases are a good thing for
the project.
My main concern (which I raised on the earlier thread) is that without
significant improvements to the release process and upstream integration
testing, it's unlikely we'll actually ship more releases. Too often,
branches are simply not in a releaseable state, or they have latent blocker
bugs due to a lack of testing. This is what we've been struggling with on
both the 2.8.x and 3.0.0-x release lines.
So, in the abstract, I'm +1 on having a published policy on release cadence
and EOL. This information helps users.
However, I don't think we're ready to actually execute on this policy for
the above reasons. This leaves me ambivalent overall, perhaps -0 since
publishing a policy we don't follow is more confusing to users.
My 2c,
Andrew
On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:
> The ASF release policy says releases may not be vetoed [1] so the EOL
> policy sounds unenforceable. Not sure a release cadence is enforceable
> either since Release Managers are volunteers.
>
> 1. https://www.apache.org/dev/release.html#approving-a-release
>
>
>
> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>
> +1 on Sangjin's proposal -
> "A minor release line is end-of-lifed 2 years after it is released or
> there
> are 2 newer minor releases, whichever is sooner. The community
> reserves the
> right to extend or shorten the life of a release line if there is a
> good
> reason to do so."
>
> I also noticed Karthik bring up some new proposals - some of them
> looks interesting to me and I have some ideas as well. Karthik, can you
> bring it out in a separated discussion threads so that we can discuss from
> there?
>
> About Chris Trezzo's question about definition of EOL of hadoop
> release, I think potentially changes could be:
> 1. For users of Apache hadoop, they would expect to upgrade to a new
> minor/major releases after EOL of their current release because there is no
> guarantee of new maintenance release.
>
> 2. For release effort, apache law claim that committer can volunteer
> RM for any release. With this release EOL proposal passes and written into
> hadoop bylaw, anyone want to call for a release which is EOL then she/he
> have to provide a good reason to community and get voted before to start
> release effort. We don't want to waste community time/resource to
> verify/vote a narrow interested release.
>
> 3. About committer's responsibility, I think the bottom line is
> committer should commit patch contributor's target release and her/his own
> interest release which I conservatively agree with Allen's point that this
> vote doesn't change anything. But if a committer want to take care more
> interest from the whole community like most committers are doing today,
> he/she should understand which branches can benefit more people and could
> skip some EOL release branches for backport effort.
>
> About major release EOL, this could be more complicated and I think we
> should discuss separately.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Allen Wittenauer <aw...@effectivemachines.com>
> Sent: Wednesday, January 18, 2017 3:30 PM
> To: Chris Trezzo
> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> Subject: Re: [VOTE] Release cadence and EOL
>
> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
>
>
>
>
Re: [VOTE] Release cadence and EOL
Posted by Andrew Wang <an...@cloudera.com>.
I don't think the motivation here is vendor play or taking away power from
committers. Having a regular release cadence helps our users understand
when a feature will ship so they can plan their upgrades. Having an EOL
policy and a minimum support period helps users choose a release line, and
understand when they will need to upgrade.
In the earlier thread, we discussed how these are not rules, but
guidelines. There's a lot of flexibility if someone wants to keep
maintaining a release line (particularly if they are willing to do the
backporting work). More power to them; more releases are a good thing for
the project.
My main concern (which I raised on the earlier thread) is that without
significant improvements to the release process and upstream integration
testing, it's unlikely we'll actually ship more releases. Too often,
branches are simply not in a releaseable state, or they have latent blocker
bugs due to a lack of testing. This is what we've been struggling with on
both the 2.8.x and 3.0.0-x release lines.
So, in the abstract, I'm +1 on having a published policy on release cadence
and EOL. This information helps users.
However, I don't think we're ready to actually execute on this policy for
the above reasons. This leaves me ambivalent overall, perhaps -0 since
publishing a policy we don't follow is more confusing to users.
My 2c,
Andrew
On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:
> The ASF release policy says releases may not be vetoed [1] so the EOL
> policy sounds unenforceable. Not sure a release cadence is enforceable
> either since Release Managers are volunteers.
>
> 1. https://www.apache.org/dev/release.html#approving-a-release
>
>
>
> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>
> +1 on Sangjin's proposal -
> "A minor release line is end-of-lifed 2 years after it is released or
> there
> are 2 newer minor releases, whichever is sooner. The community
> reserves the
> right to extend or shorten the life of a release line if there is a
> good
> reason to do so."
>
> I also noticed Karthik bring up some new proposals - some of them
> looks interesting to me and I have some ideas as well. Karthik, can you
> bring it out in a separated discussion threads so that we can discuss from
> there?
>
> About Chris Trezzo's question about definition of EOL of hadoop
> release, I think potentially changes could be:
> 1. For users of Apache hadoop, they would expect to upgrade to a new
> minor/major releases after EOL of their current release because there is no
> guarantee of new maintenance release.
>
> 2. For release effort, apache law claim that committer can volunteer
> RM for any release. With this release EOL proposal passes and written into
> hadoop bylaw, anyone want to call for a release which is EOL then she/he
> have to provide a good reason to community and get voted before to start
> release effort. We don't want to waste community time/resource to
> verify/vote a narrow interested release.
>
> 3. About committer's responsibility, I think the bottom line is
> committer should commit patch contributor's target release and her/his own
> interest release which I conservatively agree with Allen's point that this
> vote doesn't change anything. But if a committer want to take care more
> interest from the whole community like most committers are doing today,
> he/she should understand which branches can benefit more people and could
> skip some EOL release branches for backport effort.
>
> About major release EOL, this could be more complicated and I think we
> should discuss separately.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Allen Wittenauer <aw...@effectivemachines.com>
> Sent: Wednesday, January 18, 2017 3:30 PM
> To: Chris Trezzo
> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> Subject: Re: [VOTE] Release cadence and EOL
>
> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
>
>
>
>
Re: [VOTE] Release cadence and EOL
Posted by Andrew Wang <an...@cloudera.com>.
I don't think the motivation here is vendor play or taking away power from
committers. Having a regular release cadence helps our users understand
when a feature will ship so they can plan their upgrades. Having an EOL
policy and a minimum support period helps users choose a release line, and
understand when they will need to upgrade.
In the earlier thread, we discussed how these are not rules, but
guidelines. There's a lot of flexibility if someone wants to keep
maintaining a release line (particularly if they are willing to do the
backporting work). More power to them; more releases are a good thing for
the project.
My main concern (which I raised on the earlier thread) is that without
significant improvements to the release process and upstream integration
testing, it's unlikely we'll actually ship more releases. Too often,
branches are simply not in a releaseable state, or they have latent blocker
bugs due to a lack of testing. This is what we've been struggling with on
both the 2.8.x and 3.0.0-x release lines.
So, in the abstract, I'm +1 on having a published policy on release cadence
and EOL. This information helps users.
However, I don't think we're ready to actually execute on this policy for
the above reasons. This leaves me ambivalent overall, perhaps -0 since
publishing a policy we don't follow is more confusing to users.
My 2c,
Andrew
On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:
> The ASF release policy says releases may not be vetoed [1] so the EOL
> policy sounds unenforceable. Not sure a release cadence is enforceable
> either since Release Managers are volunteers.
>
> 1. https://www.apache.org/dev/release.html#approving-a-release
>
>
>
> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>
> +1 on Sangjin's proposal -
> "A minor release line is end-of-lifed 2 years after it is released or
> there
> are 2 newer minor releases, whichever is sooner. The community
> reserves the
> right to extend or shorten the life of a release line if there is a
> good
> reason to do so."
>
> I also noticed Karthik bring up some new proposals - some of them
> looks interesting to me and I have some ideas as well. Karthik, can you
> bring it out in a separated discussion threads so that we can discuss from
> there?
>
> About Chris Trezzo's question about definition of EOL of hadoop
> release, I think potentially changes could be:
> 1. For users of Apache hadoop, they would expect to upgrade to a new
> minor/major releases after EOL of their current release because there is no
> guarantee of new maintenance release.
>
> 2. For release effort, apache law claim that committer can volunteer
> RM for any release. With this release EOL proposal passes and written into
> hadoop bylaw, anyone want to call for a release which is EOL then she/he
> have to provide a good reason to community and get voted before to start
> release effort. We don't want to waste community time/resource to
> verify/vote a narrow interested release.
>
> 3. About committer's responsibility, I think the bottom line is
> committer should commit patch contributor's target release and her/his own
> interest release which I conservatively agree with Allen's point that this
> vote doesn't change anything. But if a committer want to take care more
> interest from the whole community like most committers are doing today,
> he/she should understand which branches can benefit more people and could
> skip some EOL release branches for backport effort.
>
> About major release EOL, this could be more complicated and I think we
> should discuss separately.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Allen Wittenauer <aw...@effectivemachines.com>
> Sent: Wednesday, January 18, 2017 3:30 PM
> To: Chris Trezzo
> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> Subject: Re: [VOTE] Release cadence and EOL
>
> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
>
>
>
>
Re: [VOTE] Release cadence and EOL
Posted by Andrew Wang <an...@cloudera.com>.
I don't think the motivation here is vendor play or taking away power from
committers. Having a regular release cadence helps our users understand
when a feature will ship so they can plan their upgrades. Having an EOL
policy and a minimum support period helps users choose a release line, and
understand when they will need to upgrade.
In the earlier thread, we discussed how these are not rules, but
guidelines. There's a lot of flexibility if someone wants to keep
maintaining a release line (particularly if they are willing to do the
backporting work). More power to them; more releases are a good thing for
the project.
My main concern (which I raised on the earlier thread) is that without
significant improvements to the release process and upstream integration
testing, it's unlikely we'll actually ship more releases. Too often,
branches are simply not in a releaseable state, or they have latent blocker
bugs due to a lack of testing. This is what we've been struggling with on
both the 2.8.x and 3.0.0-x release lines.
So, in the abstract, I'm +1 on having a published policy on release cadence
and EOL. This information helps users.
However, I don't think we're ready to actually execute on this policy for
the above reasons. This leaves me ambivalent overall, perhaps -0 since
publishing a policy we don't follow is more confusing to users.
My 2c,
Andrew
On Thu, Jan 19, 2017 at 12:28 PM, Arpit Agarwal <aa...@hortonworks.com>
wrote:
> The ASF release policy says releases may not be vetoed [1] so the EOL
> policy sounds unenforceable. Not sure a release cadence is enforceable
> either since Release Managers are volunteers.
>
> 1. https://www.apache.org/dev/release.html#approving-a-release
>
>
>
> On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
>
> +1 on Sangjin's proposal -
> "A minor release line is end-of-lifed 2 years after it is released or
> there
> are 2 newer minor releases, whichever is sooner. The community
> reserves the
> right to extend or shorten the life of a release line if there is a
> good
> reason to do so."
>
> I also noticed Karthik bring up some new proposals - some of them
> looks interesting to me and I have some ideas as well. Karthik, can you
> bring it out in a separated discussion threads so that we can discuss from
> there?
>
> About Chris Trezzo's question about definition of EOL of hadoop
> release, I think potentially changes could be:
> 1. For users of Apache hadoop, they would expect to upgrade to a new
> minor/major releases after EOL of their current release because there is no
> guarantee of new maintenance release.
>
> 2. For release effort, apache law claim that committer can volunteer
> RM for any release. With this release EOL proposal passes and written into
> hadoop bylaw, anyone want to call for a release which is EOL then she/he
> have to provide a good reason to community and get voted before to start
> release effort. We don't want to waste community time/resource to
> verify/vote a narrow interested release.
>
> 3. About committer's responsibility, I think the bottom line is
> committer should commit patch contributor's target release and her/his own
> interest release which I conservatively agree with Allen's point that this
> vote doesn't change anything. But if a committer want to take care more
> interest from the whole community like most committers are doing today,
> he/she should understand which branches can benefit more people and could
> skip some EOL release branches for backport effort.
>
> About major release EOL, this could be more complicated and I think we
> should discuss separately.
>
> Thanks,
>
> Junping
> ________________________________________
> From: Allen Wittenauer <aw...@effectivemachines.com>
> Sent: Wednesday, January 18, 2017 3:30 PM
> To: Chris Trezzo
> Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
> Subject: Re: [VOTE] Release cadence and EOL
>
> > On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
>
>
>
>
>
Re: [VOTE] Release cadence and EOL
Posted by Arpit Agarwal <aa...@hortonworks.com>.
The ASF release policy says releases may not be vetoed [1] so the EOL policy sounds unenforceable. Not sure a release cadence is enforceable either since Release Managers are volunteers.
1. https://www.apache.org/dev/release.html#approving-a-release
On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
+1 on Sangjin's proposal -
"A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so."
I also noticed Karthik bring up some new proposals - some of them looks interesting to me and I have some ideas as well. Karthik, can you bring it out in a separated discussion threads so that we can discuss from there?
About Chris Trezzo's question about definition of EOL of hadoop release, I think potentially changes could be:
1. For users of Apache hadoop, they would expect to upgrade to a new minor/major releases after EOL of their current release because there is no guarantee of new maintenance release.
2. For release effort, apache law claim that committer can volunteer RM for any release. With this release EOL proposal passes and written into hadoop bylaw, anyone want to call for a release which is EOL then she/he have to provide a good reason to community and get voted before to start release effort. We don't want to waste community time/resource to verify/vote a narrow interested release.
3. About committer's responsibility, I think the bottom line is committer should commit patch contributor's target release and her/his own interest release which I conservatively agree with Allen's point that this vote doesn't change anything. But if a committer want to take care more interest from the whole community like most committers are doing today, he/she should understand which branches can benefit more people and could skip some EOL release branches for backport effort.
About major release EOL, this could be more complicated and I think we should discuss separately.
Thanks,
Junping
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Arpit Agarwal <aa...@hortonworks.com>.
The ASF release policy says releases may not be vetoed [1] so the EOL policy sounds unenforceable. Not sure a release cadence is enforceable either since Release Managers are volunteers.
1. https://www.apache.org/dev/release.html#approving-a-release
On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
+1 on Sangjin's proposal -
"A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so."
I also noticed Karthik bring up some new proposals - some of them looks interesting to me and I have some ideas as well. Karthik, can you bring it out in a separated discussion threads so that we can discuss from there?
About Chris Trezzo's question about definition of EOL of hadoop release, I think potentially changes could be:
1. For users of Apache hadoop, they would expect to upgrade to a new minor/major releases after EOL of their current release because there is no guarantee of new maintenance release.
2. For release effort, apache law claim that committer can volunteer RM for any release. With this release EOL proposal passes and written into hadoop bylaw, anyone want to call for a release which is EOL then she/he have to provide a good reason to community and get voted before to start release effort. We don't want to waste community time/resource to verify/vote a narrow interested release.
3. About committer's responsibility, I think the bottom line is committer should commit patch contributor's target release and her/his own interest release which I conservatively agree with Allen's point that this vote doesn't change anything. But if a committer want to take care more interest from the whole community like most committers are doing today, he/she should understand which branches can benefit more people and could skip some EOL release branches for backport effort.
About major release EOL, this could be more complicated and I think we should discuss separately.
Thanks,
Junping
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Arpit Agarwal <aa...@hortonworks.com>.
The ASF release policy says releases may not be vetoed [1] so the EOL policy sounds unenforceable. Not sure a release cadence is enforceable either since Release Managers are volunteers.
1. https://www.apache.org/dev/release.html#approving-a-release
On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
+1 on Sangjin's proposal -
"A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so."
I also noticed Karthik bring up some new proposals - some of them looks interesting to me and I have some ideas as well. Karthik, can you bring it out in a separated discussion threads so that we can discuss from there?
About Chris Trezzo's question about definition of EOL of hadoop release, I think potentially changes could be:
1. For users of Apache hadoop, they would expect to upgrade to a new minor/major releases after EOL of their current release because there is no guarantee of new maintenance release.
2. For release effort, apache law claim that committer can volunteer RM for any release. With this release EOL proposal passes and written into hadoop bylaw, anyone want to call for a release which is EOL then she/he have to provide a good reason to community and get voted before to start release effort. We don't want to waste community time/resource to verify/vote a narrow interested release.
3. About committer's responsibility, I think the bottom line is committer should commit patch contributor's target release and her/his own interest release which I conservatively agree with Allen's point that this vote doesn't change anything. But if a committer want to take care more interest from the whole community like most committers are doing today, he/she should understand which branches can benefit more people and could skip some EOL release branches for backport effort.
About major release EOL, this could be more complicated and I think we should discuss separately.
Thanks,
Junping
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Arpit Agarwal <aa...@hortonworks.com>.
The ASF release policy says releases may not be vetoed [1] so the EOL policy sounds unenforceable. Not sure a release cadence is enforceable either since Release Managers are volunteers.
1. https://www.apache.org/dev/release.html#approving-a-release
On 1/18/17, 7:06 PM, "Junping Du" <jd...@hortonworks.com> wrote:
+1 on Sangjin's proposal -
"A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so."
I also noticed Karthik bring up some new proposals - some of them looks interesting to me and I have some ideas as well. Karthik, can you bring it out in a separated discussion threads so that we can discuss from there?
About Chris Trezzo's question about definition of EOL of hadoop release, I think potentially changes could be:
1. For users of Apache hadoop, they would expect to upgrade to a new minor/major releases after EOL of their current release because there is no guarantee of new maintenance release.
2. For release effort, apache law claim that committer can volunteer RM for any release. With this release EOL proposal passes and written into hadoop bylaw, anyone want to call for a release which is EOL then she/he have to provide a good reason to community and get voted before to start release effort. We don't want to waste community time/resource to verify/vote a narrow interested release.
3. About committer's responsibility, I think the bottom line is committer should commit patch contributor's target release and her/his own interest release which I conservatively agree with Allen's point that this vote doesn't change anything. But if a committer want to take care more interest from the whole community like most committers are doing today, he/she should understand which branches can benefit more people and could skip some EOL release branches for backport effort.
About major release EOL, this could be more complicated and I think we should discuss separately.
Thanks,
Junping
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Junping Du <jd...@hortonworks.com>.
+1 on Sangjin's proposal -
"A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so."
I also noticed Karthik bring up some new proposals - some of them looks interesting to me and I have some ideas as well. Karthik, can you bring it out in a separated discussion threads so that we can discuss from there?
About Chris Trezzo's question about definition of EOL of hadoop release, I think potentially changes could be:
1. For users of Apache hadoop, they would expect to upgrade to a new minor/major releases after EOL of their current release because there is no guarantee of new maintenance release.
2. For release effort, apache law claim that committer can volunteer RM for any release. With this release EOL proposal passes and written into hadoop bylaw, anyone want to call for a release which is EOL then she/he have to provide a good reason to community and get voted before to start release effort. We don't want to waste community time/resource to verify/vote a narrow interested release.
3. About committer's responsibility, I think the bottom line is committer should commit patch contributor's target release and her/his own interest release which I conservatively agree with Allen's point that this vote doesn't change anything. But if a committer want to take care more interest from the whole community like most committers are doing today, he/she should understand which branches can benefit more people and could skip some EOL release branches for backport effort.
About major release EOL, this could be more complicated and I think we should discuss separately.
Thanks,
Junping
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Junping Du <jd...@hortonworks.com>.
+1 on Sangjin's proposal -
"A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so."
I also noticed Karthik bring up some new proposals - some of them looks interesting to me and I have some ideas as well. Karthik, can you bring it out in a separated discussion threads so that we can discuss from there?
About Chris Trezzo's question about definition of EOL of hadoop release, I think potentially changes could be:
1. For users of Apache hadoop, they would expect to upgrade to a new minor/major releases after EOL of their current release because there is no guarantee of new maintenance release.
2. For release effort, apache law claim that committer can volunteer RM for any release. With this release EOL proposal passes and written into hadoop bylaw, anyone want to call for a release which is EOL then she/he have to provide a good reason to community and get voted before to start release effort. We don't want to waste community time/resource to verify/vote a narrow interested release.
3. About committer's responsibility, I think the bottom line is committer should commit patch contributor's target release and her/his own interest release which I conservatively agree with Allen's point that this vote doesn't change anything. But if a committer want to take care more interest from the whole community like most committers are doing today, he/she should understand which branches can benefit more people and could skip some EOL release branches for backport effort.
About major release EOL, this could be more complicated and I think we should discuss separately.
Thanks,
Junping
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Junping Du <jd...@hortonworks.com>.
+1 on Sangjin's proposal -
"A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so."
I also noticed Karthik bring up some new proposals - some of them looks interesting to me and I have some ideas as well. Karthik, can you bring it out in a separated discussion threads so that we can discuss from there?
About Chris Trezzo's question about definition of EOL of hadoop release, I think potentially changes could be:
1. For users of Apache hadoop, they would expect to upgrade to a new minor/major releases after EOL of their current release because there is no guarantee of new maintenance release.
2. For release effort, apache law claim that committer can volunteer RM for any release. With this release EOL proposal passes and written into hadoop bylaw, anyone want to call for a release which is EOL then she/he have to provide a good reason to community and get voted before to start release effort. We don't want to waste community time/resource to verify/vote a narrow interested release.
3. About committer's responsibility, I think the bottom line is committer should commit patch contributor's target release and her/his own interest release which I conservatively agree with Allen's point that this vote doesn't change anything. But if a committer want to take care more interest from the whole community like most committers are doing today, he/she should understand which branches can benefit more people and could skip some EOL release branches for backport effort.
About major release EOL, this could be more complicated and I think we should discuss separately.
Thanks,
Junping
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Junping Du <jd...@hortonworks.com>.
+1 on Sangjin's proposal -
"A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so."
I also noticed Karthik bring up some new proposals - some of them looks interesting to me and I have some ideas as well. Karthik, can you bring it out in a separated discussion threads so that we can discuss from there?
About Chris Trezzo's question about definition of EOL of hadoop release, I think potentially changes could be:
1. For users of Apache hadoop, they would expect to upgrade to a new minor/major releases after EOL of their current release because there is no guarantee of new maintenance release.
2. For release effort, apache law claim that committer can volunteer RM for any release. With this release EOL proposal passes and written into hadoop bylaw, anyone want to call for a release which is EOL then she/he have to provide a good reason to community and get voted before to start release effort. We don't want to waste community time/resource to verify/vote a narrow interested release.
3. About committer's responsibility, I think the bottom line is committer should commit patch contributor's target release and her/his own interest release which I conservatively agree with Allen's point that this vote doesn't change anything. But if a committer want to take care more interest from the whole community like most committers are doing today, he/she should understand which branches can benefit more people and could skip some EOL release branches for backport effort.
About major release EOL, this could be more complicated and I think we should discuss separately.
Thanks,
Junping
________________________________________
From: Allen Wittenauer <aw...@effectivemachines.com>
Sent: Wednesday, January 18, 2017 3:30 PM
To: Chris Trezzo
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org
Subject: Re: [VOTE] Release cadence and EOL
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Jan 18, 2017, at 11:21 AM, Chris Trezzo <ct...@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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Chris Trezzo <ct...@gmail.com>.
Thanks Sangjin for pushing this forward! I have a few questions:
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.
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?
Thanks!
On Tue, Jan 17, 2017 at 10:32 AM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> +1
>
> I would also like to see some process guidelines. I should have brought
> this up on the discussion thread, but I thought of them only now :(
>
> - Is an RM responsible for all maintenance releases against a minor
> release, or finding another RM to drive a maintenance release? In the
> past,
> this hasn't been a major issue.
> - When do we pick/volunteer to RM a minor release? IMO, this should be
> right after the previous release goes out. For example, Junping is
> driving
> 2.8.0 now. As soon as that is done, we need to find a volunteer to RM
> 2.9.0
> 6 months after.
> - The release process has multiple steps, based on
> major/minor/maintenance. It would be nice to capture/track how long each
> step takes so the RM can be prepared. e.g. herding the cats for an RC
> takes
> x weeks, compatibility checks take y days of work.
>
>
> On Tue, Jan 17, 2017 at 10:05 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> > Thanks for correcting me! I left out a sentence by mistake. :)
> >
> > To correct the proposal we're voting for:
> >
> > A minor release on the latest major line should be every 6 months, and a
> > maintenance release on a minor release (as there may be concurrently
> > maintained minor releases) every 2 months.
> >
> > A minor release line is end-of-lifed 2 years after it is released or
> there
> > are 2 newer minor releases, whichever is sooner. The community reserves
> the
> > right to extend or shorten the life of a release line if there is a good
> > reason to do so.
> >
> > Sorry for the snafu.
> >
> > Regards,
> > Sangjin
> >
> > On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
> > wrote:
> >
> > > Thanks for driving this, Sangjin. Quick question, though: the subject
> > line
> > > is "Release cadence and EOL," but I don't see anything about cadence in
> > the
> > > proposal. Did I miss something?
> > >
> > > Daniel
> > >
> > >
> > > On 1/17/17 8:35 AM, Sangjin Lee wrote:
> > >
> > >> Following up on the discussion thread on this topic (
> > >> https://s.apache.org/eFOf), I'd like to put the proposal for a vote
> for
> > >> the
> > >> release cadence and EOL. The proposal is as follows:
> > >>
> > >> "A minor release line is end-of-lifed 2 years after it is released or
> > >> there
> > >> are 2 newer minor releases, whichever is sooner. The community
> reserves
> > >> the
> > >> right to extend or shorten the life of a release line if there is a
> good
> > >> reason to do so."
> > >>
> > >> This also entails that we the Hadoop community commit to following
> this
> > >> practice and solving challenges to make it possible. Andrew Wang laid
> > out
> > >> some of those challenges and what can be done in the discussion thread
> > >> mentioned above.
> > >>
> > >> I'll set the voting period to 7 days. I understand a majority rule
> would
> > >> apply in this case. Your vote is greatly appreciated, and so are
> > >> suggestions!
> > >>
> > >> Thanks,
> > >> Sangjin
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: common-dev-help@hadoop.apache.org
> > >
> > >
> >
>
Re: [VOTE] Release cadence and EOL
Posted by Chris Trezzo <ct...@gmail.com>.
Thanks Sangjin for pushing this forward! I have a few questions:
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.
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?
Thanks!
On Tue, Jan 17, 2017 at 10:32 AM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> +1
>
> I would also like to see some process guidelines. I should have brought
> this up on the discussion thread, but I thought of them only now :(
>
> - Is an RM responsible for all maintenance releases against a minor
> release, or finding another RM to drive a maintenance release? In the
> past,
> this hasn't been a major issue.
> - When do we pick/volunteer to RM a minor release? IMO, this should be
> right after the previous release goes out. For example, Junping is
> driving
> 2.8.0 now. As soon as that is done, we need to find a volunteer to RM
> 2.9.0
> 6 months after.
> - The release process has multiple steps, based on
> major/minor/maintenance. It would be nice to capture/track how long each
> step takes so the RM can be prepared. e.g. herding the cats for an RC
> takes
> x weeks, compatibility checks take y days of work.
>
>
> On Tue, Jan 17, 2017 at 10:05 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> > Thanks for correcting me! I left out a sentence by mistake. :)
> >
> > To correct the proposal we're voting for:
> >
> > A minor release on the latest major line should be every 6 months, and a
> > maintenance release on a minor release (as there may be concurrently
> > maintained minor releases) every 2 months.
> >
> > A minor release line is end-of-lifed 2 years after it is released or
> there
> > are 2 newer minor releases, whichever is sooner. The community reserves
> the
> > right to extend or shorten the life of a release line if there is a good
> > reason to do so.
> >
> > Sorry for the snafu.
> >
> > Regards,
> > Sangjin
> >
> > On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
> > wrote:
> >
> > > Thanks for driving this, Sangjin. Quick question, though: the subject
> > line
> > > is "Release cadence and EOL," but I don't see anything about cadence in
> > the
> > > proposal. Did I miss something?
> > >
> > > Daniel
> > >
> > >
> > > On 1/17/17 8:35 AM, Sangjin Lee wrote:
> > >
> > >> Following up on the discussion thread on this topic (
> > >> https://s.apache.org/eFOf), I'd like to put the proposal for a vote
> for
> > >> the
> > >> release cadence and EOL. The proposal is as follows:
> > >>
> > >> "A minor release line is end-of-lifed 2 years after it is released or
> > >> there
> > >> are 2 newer minor releases, whichever is sooner. The community
> reserves
> > >> the
> > >> right to extend or shorten the life of a release line if there is a
> good
> > >> reason to do so."
> > >>
> > >> This also entails that we the Hadoop community commit to following
> this
> > >> practice and solving challenges to make it possible. Andrew Wang laid
> > out
> > >> some of those challenges and what can be done in the discussion thread
> > >> mentioned above.
> > >>
> > >> I'll set the voting period to 7 days. I understand a majority rule
> would
> > >> apply in this case. Your vote is greatly appreciated, and so are
> > >> suggestions!
> > >>
> > >> Thanks,
> > >> Sangjin
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: common-dev-help@hadoop.apache.org
> > >
> > >
> >
>
Re: [VOTE] Release cadence and EOL
Posted by Chris Trezzo <ct...@gmail.com>.
Thanks Sangjin for pushing this forward! I have a few questions:
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.
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?
Thanks!
On Tue, Jan 17, 2017 at 10:32 AM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> +1
>
> I would also like to see some process guidelines. I should have brought
> this up on the discussion thread, but I thought of them only now :(
>
> - Is an RM responsible for all maintenance releases against a minor
> release, or finding another RM to drive a maintenance release? In the
> past,
> this hasn't been a major issue.
> - When do we pick/volunteer to RM a minor release? IMO, this should be
> right after the previous release goes out. For example, Junping is
> driving
> 2.8.0 now. As soon as that is done, we need to find a volunteer to RM
> 2.9.0
> 6 months after.
> - The release process has multiple steps, based on
> major/minor/maintenance. It would be nice to capture/track how long each
> step takes so the RM can be prepared. e.g. herding the cats for an RC
> takes
> x weeks, compatibility checks take y days of work.
>
>
> On Tue, Jan 17, 2017 at 10:05 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> > Thanks for correcting me! I left out a sentence by mistake. :)
> >
> > To correct the proposal we're voting for:
> >
> > A minor release on the latest major line should be every 6 months, and a
> > maintenance release on a minor release (as there may be concurrently
> > maintained minor releases) every 2 months.
> >
> > A minor release line is end-of-lifed 2 years after it is released or
> there
> > are 2 newer minor releases, whichever is sooner. The community reserves
> the
> > right to extend or shorten the life of a release line if there is a good
> > reason to do so.
> >
> > Sorry for the snafu.
> >
> > Regards,
> > Sangjin
> >
> > On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
> > wrote:
> >
> > > Thanks for driving this, Sangjin. Quick question, though: the subject
> > line
> > > is "Release cadence and EOL," but I don't see anything about cadence in
> > the
> > > proposal. Did I miss something?
> > >
> > > Daniel
> > >
> > >
> > > On 1/17/17 8:35 AM, Sangjin Lee wrote:
> > >
> > >> Following up on the discussion thread on this topic (
> > >> https://s.apache.org/eFOf), I'd like to put the proposal for a vote
> for
> > >> the
> > >> release cadence and EOL. The proposal is as follows:
> > >>
> > >> "A minor release line is end-of-lifed 2 years after it is released or
> > >> there
> > >> are 2 newer minor releases, whichever is sooner. The community
> reserves
> > >> the
> > >> right to extend or shorten the life of a release line if there is a
> good
> > >> reason to do so."
> > >>
> > >> This also entails that we the Hadoop community commit to following
> this
> > >> practice and solving challenges to make it possible. Andrew Wang laid
> > out
> > >> some of those challenges and what can be done in the discussion thread
> > >> mentioned above.
> > >>
> > >> I'll set the voting period to 7 days. I understand a majority rule
> would
> > >> apply in this case. Your vote is greatly appreciated, and so are
> > >> suggestions!
> > >>
> > >> Thanks,
> > >> Sangjin
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: common-dev-help@hadoop.apache.org
> > >
> > >
> >
>
Re: [VOTE] Release cadence and EOL
Posted by Chris Trezzo <ct...@gmail.com>.
Thanks Sangjin for pushing this forward! I have a few questions:
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.
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?
Thanks!
On Tue, Jan 17, 2017 at 10:32 AM, Karthik Kambatla <ka...@cloudera.com>
wrote:
> +1
>
> I would also like to see some process guidelines. I should have brought
> this up on the discussion thread, but I thought of them only now :(
>
> - Is an RM responsible for all maintenance releases against a minor
> release, or finding another RM to drive a maintenance release? In the
> past,
> this hasn't been a major issue.
> - When do we pick/volunteer to RM a minor release? IMO, this should be
> right after the previous release goes out. For example, Junping is
> driving
> 2.8.0 now. As soon as that is done, we need to find a volunteer to RM
> 2.9.0
> 6 months after.
> - The release process has multiple steps, based on
> major/minor/maintenance. It would be nice to capture/track how long each
> step takes so the RM can be prepared. e.g. herding the cats for an RC
> takes
> x weeks, compatibility checks take y days of work.
>
>
> On Tue, Jan 17, 2017 at 10:05 AM, Sangjin Lee <sj...@apache.org> wrote:
>
> > Thanks for correcting me! I left out a sentence by mistake. :)
> >
> > To correct the proposal we're voting for:
> >
> > A minor release on the latest major line should be every 6 months, and a
> > maintenance release on a minor release (as there may be concurrently
> > maintained minor releases) every 2 months.
> >
> > A minor release line is end-of-lifed 2 years after it is released or
> there
> > are 2 newer minor releases, whichever is sooner. The community reserves
> the
> > right to extend or shorten the life of a release line if there is a good
> > reason to do so.
> >
> > Sorry for the snafu.
> >
> > Regards,
> > Sangjin
> >
> > On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
> > wrote:
> >
> > > Thanks for driving this, Sangjin. Quick question, though: the subject
> > line
> > > is "Release cadence and EOL," but I don't see anything about cadence in
> > the
> > > proposal. Did I miss something?
> > >
> > > Daniel
> > >
> > >
> > > On 1/17/17 8:35 AM, Sangjin Lee wrote:
> > >
> > >> Following up on the discussion thread on this topic (
> > >> https://s.apache.org/eFOf), I'd like to put the proposal for a vote
> for
> > >> the
> > >> release cadence and EOL. The proposal is as follows:
> > >>
> > >> "A minor release line is end-of-lifed 2 years after it is released or
> > >> there
> > >> are 2 newer minor releases, whichever is sooner. The community
> reserves
> > >> the
> > >> right to extend or shorten the life of a release line if there is a
> good
> > >> reason to do so."
> > >>
> > >> This also entails that we the Hadoop community commit to following
> this
> > >> practice and solving challenges to make it possible. Andrew Wang laid
> > out
> > >> some of those challenges and what can be done in the discussion thread
> > >> mentioned above.
> > >>
> > >> I'll set the voting period to 7 days. I understand a majority rule
> would
> > >> apply in this case. Your vote is greatly appreciated, and so are
> > >> suggestions!
> > >>
> > >> Thanks,
> > >> Sangjin
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> > > For additional commands, e-mail: common-dev-help@hadoop.apache.org
> > >
> > >
> >
>
Re: [VOTE] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
+1
I would also like to see some process guidelines. I should have brought
this up on the discussion thread, but I thought of them only now :(
- Is an RM responsible for all maintenance releases against a minor
release, or finding another RM to drive a maintenance release? In the past,
this hasn't been a major issue.
- When do we pick/volunteer to RM a minor release? IMO, this should be
right after the previous release goes out. For example, Junping is driving
2.8.0 now. As soon as that is done, we need to find a volunteer to RM 2.9.0
6 months after.
- The release process has multiple steps, based on
major/minor/maintenance. It would be nice to capture/track how long each
step takes so the RM can be prepared. e.g. herding the cats for an RC takes
x weeks, compatibility checks take y days of work.
On Tue, Jan 17, 2017 at 10:05 AM, Sangjin Lee <sj...@apache.org> wrote:
> Thanks for correcting me! I left out a sentence by mistake. :)
>
> To correct the proposal we're voting for:
>
> A minor release on the latest major line should be every 6 months, and a
> maintenance release on a minor release (as there may be concurrently
> maintained minor releases) every 2 months.
>
> A minor release line is end-of-lifed 2 years after it is released or there
> are 2 newer minor releases, whichever is sooner. The community reserves the
> right to extend or shorten the life of a release line if there is a good
> reason to do so.
>
> Sorry for the snafu.
>
> Regards,
> Sangjin
>
> On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
> wrote:
>
> > Thanks for driving this, Sangjin. Quick question, though: the subject
> line
> > is "Release cadence and EOL," but I don't see anything about cadence in
> the
> > proposal. Did I miss something?
> >
> > Daniel
> >
> >
> > On 1/17/17 8:35 AM, Sangjin Lee wrote:
> >
> >> Following up on the discussion thread on this topic (
> >> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for
> >> the
> >> release cadence and EOL. The proposal is as follows:
> >>
> >> "A minor release line is end-of-lifed 2 years after it is released or
> >> there
> >> are 2 newer minor releases, whichever is sooner. The community reserves
> >> the
> >> right to extend or shorten the life of a release line if there is a good
> >> reason to do so."
> >>
> >> This also entails that we the Hadoop community commit to following this
> >> practice and solving challenges to make it possible. Andrew Wang laid
> out
> >> some of those challenges and what can be done in the discussion thread
> >> mentioned above.
> >>
> >> I'll set the voting period to 7 days. I understand a majority rule would
> >> apply in this case. Your vote is greatly appreciated, and so are
> >> suggestions!
> >>
> >> Thanks,
> >> Sangjin
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: common-dev-help@hadoop.apache.org
> >
> >
>
Re: [VOTE] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
+1
I would also like to see some process guidelines. I should have brought
this up on the discussion thread, but I thought of them only now :(
- Is an RM responsible for all maintenance releases against a minor
release, or finding another RM to drive a maintenance release? In the past,
this hasn't been a major issue.
- When do we pick/volunteer to RM a minor release? IMO, this should be
right after the previous release goes out. For example, Junping is driving
2.8.0 now. As soon as that is done, we need to find a volunteer to RM 2.9.0
6 months after.
- The release process has multiple steps, based on
major/minor/maintenance. It would be nice to capture/track how long each
step takes so the RM can be prepared. e.g. herding the cats for an RC takes
x weeks, compatibility checks take y days of work.
On Tue, Jan 17, 2017 at 10:05 AM, Sangjin Lee <sj...@apache.org> wrote:
> Thanks for correcting me! I left out a sentence by mistake. :)
>
> To correct the proposal we're voting for:
>
> A minor release on the latest major line should be every 6 months, and a
> maintenance release on a minor release (as there may be concurrently
> maintained minor releases) every 2 months.
>
> A minor release line is end-of-lifed 2 years after it is released or there
> are 2 newer minor releases, whichever is sooner. The community reserves the
> right to extend or shorten the life of a release line if there is a good
> reason to do so.
>
> Sorry for the snafu.
>
> Regards,
> Sangjin
>
> On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
> wrote:
>
> > Thanks for driving this, Sangjin. Quick question, though: the subject
> line
> > is "Release cadence and EOL," but I don't see anything about cadence in
> the
> > proposal. Did I miss something?
> >
> > Daniel
> >
> >
> > On 1/17/17 8:35 AM, Sangjin Lee wrote:
> >
> >> Following up on the discussion thread on this topic (
> >> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for
> >> the
> >> release cadence and EOL. The proposal is as follows:
> >>
> >> "A minor release line is end-of-lifed 2 years after it is released or
> >> there
> >> are 2 newer minor releases, whichever is sooner. The community reserves
> >> the
> >> right to extend or shorten the life of a release line if there is a good
> >> reason to do so."
> >>
> >> This also entails that we the Hadoop community commit to following this
> >> practice and solving challenges to make it possible. Andrew Wang laid
> out
> >> some of those challenges and what can be done in the discussion thread
> >> mentioned above.
> >>
> >> I'll set the voting period to 7 days. I understand a majority rule would
> >> apply in this case. Your vote is greatly appreciated, and so are
> >> suggestions!
> >>
> >> Thanks,
> >> Sangjin
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: common-dev-help@hadoop.apache.org
> >
> >
>
Re: [VOTE] Release cadence and EOL
Posted by Karthik Kambatla <ka...@cloudera.com>.
+1
I would also like to see some process guidelines. I should have brought
this up on the discussion thread, but I thought of them only now :(
- Is an RM responsible for all maintenance releases against a minor
release, or finding another RM to drive a maintenance release? In the past,
this hasn't been a major issue.
- When do we pick/volunteer to RM a minor release? IMO, this should be
right after the previous release goes out. For example, Junping is driving
2.8.0 now. As soon as that is done, we need to find a volunteer to RM 2.9.0
6 months after.
- The release process has multiple steps, based on
major/minor/maintenance. It would be nice to capture/track how long each
step takes so the RM can be prepared. e.g. herding the cats for an RC takes
x weeks, compatibility checks take y days of work.
On Tue, Jan 17, 2017 at 10:05 AM, Sangjin Lee <sj...@apache.org> wrote:
> Thanks for correcting me! I left out a sentence by mistake. :)
>
> To correct the proposal we're voting for:
>
> A minor release on the latest major line should be every 6 months, and a
> maintenance release on a minor release (as there may be concurrently
> maintained minor releases) every 2 months.
>
> A minor release line is end-of-lifed 2 years after it is released or there
> are 2 newer minor releases, whichever is sooner. The community reserves the
> right to extend or shorten the life of a release line if there is a good
> reason to do so.
>
> Sorry for the snafu.
>
> Regards,
> Sangjin
>
> On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
> wrote:
>
> > Thanks for driving this, Sangjin. Quick question, though: the subject
> line
> > is "Release cadence and EOL," but I don't see anything about cadence in
> the
> > proposal. Did I miss something?
> >
> > Daniel
> >
> >
> > On 1/17/17 8:35 AM, Sangjin Lee wrote:
> >
> >> Following up on the discussion thread on this topic (
> >> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for
> >> the
> >> release cadence and EOL. The proposal is as follows:
> >>
> >> "A minor release line is end-of-lifed 2 years after it is released or
> >> there
> >> are 2 newer minor releases, whichever is sooner. The community reserves
> >> the
> >> right to extend or shorten the life of a release line if there is a good
> >> reason to do so."
> >>
> >> This also entails that we the Hadoop community commit to following this
> >> practice and solving challenges to make it possible. Andrew Wang laid
> out
> >> some of those challenges and what can be done in the discussion thread
> >> mentioned above.
> >>
> >> I'll set the voting period to 7 days. I understand a majority rule would
> >> apply in this case. Your vote is greatly appreciated, and so are
> >> suggestions!
> >>
> >> Thanks,
> >> Sangjin
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> > For additional commands, e-mail: common-dev-help@hadoop.apache.org
> >
> >
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks for correcting me! I left out a sentence by mistake. :)
To correct the proposal we're voting for:
A minor release on the latest major line should be every 6 months, and a
maintenance release on a minor release (as there may be concurrently
maintained minor releases) every 2 months.
A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so.
Sorry for the snafu.
Regards,
Sangjin
On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
wrote:
> Thanks for driving this, Sangjin. Quick question, though: the subject line
> is "Release cadence and EOL," but I don't see anything about cadence in the
> proposal. Did I miss something?
>
> Daniel
>
>
> On 1/17/17 8:35 AM, Sangjin Lee wrote:
>
>> Following up on the discussion thread on this topic (
>> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for
>> the
>> release cadence and EOL. The proposal is as follows:
>>
>> "A minor release line is end-of-lifed 2 years after it is released or
>> there
>> are 2 newer minor releases, whichever is sooner. The community reserves
>> the
>> right to extend or shorten the life of a release line if there is a good
>> reason to do so."
>>
>> This also entails that we the Hadoop community commit to following this
>> practice and solving challenges to make it possible. Andrew Wang laid out
>> some of those challenges and what can be done in the discussion thread
>> mentioned above.
>>
>> I'll set the voting period to 7 days. I understand a majority rule would
>> apply in this case. Your vote is greatly appreciated, and so are
>> suggestions!
>>
>> Thanks,
>> Sangjin
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks for correcting me! I left out a sentence by mistake. :)
To correct the proposal we're voting for:
A minor release on the latest major line should be every 6 months, and a
maintenance release on a minor release (as there may be concurrently
maintained minor releases) every 2 months.
A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so.
Sorry for the snafu.
Regards,
Sangjin
On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
wrote:
> Thanks for driving this, Sangjin. Quick question, though: the subject line
> is "Release cadence and EOL," but I don't see anything about cadence in the
> proposal. Did I miss something?
>
> Daniel
>
>
> On 1/17/17 8:35 AM, Sangjin Lee wrote:
>
>> Following up on the discussion thread on this topic (
>> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for
>> the
>> release cadence and EOL. The proposal is as follows:
>>
>> "A minor release line is end-of-lifed 2 years after it is released or
>> there
>> are 2 newer minor releases, whichever is sooner. The community reserves
>> the
>> right to extend or shorten the life of a release line if there is a good
>> reason to do so."
>>
>> This also entails that we the Hadoop community commit to following this
>> practice and solving challenges to make it possible. Andrew Wang laid out
>> some of those challenges and what can be done in the discussion thread
>> mentioned above.
>>
>> I'll set the voting period to 7 days. I understand a majority rule would
>> apply in this case. Your vote is greatly appreciated, and so are
>> suggestions!
>>
>> Thanks,
>> Sangjin
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks for correcting me! I left out a sentence by mistake. :)
To correct the proposal we're voting for:
A minor release on the latest major line should be every 6 months, and a
maintenance release on a minor release (as there may be concurrently
maintained minor releases) every 2 months.
A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so.
Sorry for the snafu.
Regards,
Sangjin
On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
wrote:
> Thanks for driving this, Sangjin. Quick question, though: the subject line
> is "Release cadence and EOL," but I don't see anything about cadence in the
> proposal. Did I miss something?
>
> Daniel
>
>
> On 1/17/17 8:35 AM, Sangjin Lee wrote:
>
>> Following up on the discussion thread on this topic (
>> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for
>> the
>> release cadence and EOL. The proposal is as follows:
>>
>> "A minor release line is end-of-lifed 2 years after it is released or
>> there
>> are 2 newer minor releases, whichever is sooner. The community reserves
>> the
>> right to extend or shorten the life of a release line if there is a good
>> reason to do so."
>>
>> This also entails that we the Hadoop community commit to following this
>> practice and solving challenges to make it possible. Andrew Wang laid out
>> some of those challenges and what can be done in the discussion thread
>> mentioned above.
>>
>> I'll set the voting period to 7 days. I understand a majority rule would
>> apply in this case. Your vote is greatly appreciated, and so are
>> suggestions!
>>
>> Thanks,
>> Sangjin
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Sangjin Lee <sj...@apache.org>.
Thanks for correcting me! I left out a sentence by mistake. :)
To correct the proposal we're voting for:
A minor release on the latest major line should be every 6 months, and a
maintenance release on a minor release (as there may be concurrently
maintained minor releases) every 2 months.
A minor release line is end-of-lifed 2 years after it is released or there
are 2 newer minor releases, whichever is sooner. The community reserves the
right to extend or shorten the life of a release line if there is a good
reason to do so.
Sorry for the snafu.
Regards,
Sangjin
On Tue, Jan 17, 2017 at 9:58 AM, Daniel Templeton <da...@cloudera.com>
wrote:
> Thanks for driving this, Sangjin. Quick question, though: the subject line
> is "Release cadence and EOL," but I don't see anything about cadence in the
> proposal. Did I miss something?
>
> Daniel
>
>
> On 1/17/17 8:35 AM, Sangjin Lee wrote:
>
>> Following up on the discussion thread on this topic (
>> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for
>> the
>> release cadence and EOL. The proposal is as follows:
>>
>> "A minor release line is end-of-lifed 2 years after it is released or
>> there
>> are 2 newer minor releases, whichever is sooner. The community reserves
>> the
>> right to extend or shorten the life of a release line if there is a good
>> reason to do so."
>>
>> This also entails that we the Hadoop community commit to following this
>> practice and solving challenges to make it possible. Andrew Wang laid out
>> some of those challenges and what can be done in the discussion thread
>> mentioned above.
>>
>> I'll set the voting period to 7 days. I understand a majority rule would
>> apply in this case. Your vote is greatly appreciated, and so are
>> suggestions!
>>
>> Thanks,
>> Sangjin
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>
>
Re: [VOTE] Release cadence and EOL
Posted by Daniel Templeton <da...@cloudera.com>.
Thanks for driving this, Sangjin. Quick question, though: the subject
line is "Release cadence and EOL," but I don't see anything about
cadence in the proposal. Did I miss something?
Daniel
On 1/17/17 8:35 AM, Sangjin Lee wrote:
> Following up on the discussion thread on this topic (
> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for the
> release cadence and EOL. The proposal is as follows:
>
> "A minor release line is end-of-lifed 2 years after it is released or there
> are 2 newer minor releases, whichever is sooner. The community reserves the
> right to extend or shorten the life of a release line if there is a good
> reason to do so."
>
> This also entails that we the Hadoop community commit to following this
> practice and solving challenges to make it possible. Andrew Wang laid out
> some of those challenges and what can be done in the discussion thread
> mentioned above.
>
> I'll set the voting period to 7 days. I understand a majority rule would
> apply in this case. Your vote is greatly appreciated, and so are
> suggestions!
>
> Thanks,
> Sangjin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Daniel Templeton <da...@cloudera.com>.
Thanks for driving this, Sangjin. Quick question, though: the subject
line is "Release cadence and EOL," but I don't see anything about
cadence in the proposal. Did I miss something?
Daniel
On 1/17/17 8:35 AM, Sangjin Lee wrote:
> Following up on the discussion thread on this topic (
> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for the
> release cadence and EOL. The proposal is as follows:
>
> "A minor release line is end-of-lifed 2 years after it is released or there
> are 2 newer minor releases, whichever is sooner. The community reserves the
> right to extend or shorten the life of a release line if there is a good
> reason to do so."
>
> This also entails that we the Hadoop community commit to following this
> practice and solving challenges to make it possible. Andrew Wang laid out
> some of those challenges and what can be done in the discussion thread
> mentioned above.
>
> I'll set the voting period to 7 days. I understand a majority rule would
> apply in this case. Your vote is greatly appreciated, and so are
> suggestions!
>
> Thanks,
> Sangjin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Daniel Templeton <da...@cloudera.com>.
Thanks for driving this, Sangjin. Quick question, though: the subject
line is "Release cadence and EOL," but I don't see anything about
cadence in the proposal. Did I miss something?
Daniel
On 1/17/17 8:35 AM, Sangjin Lee wrote:
> Following up on the discussion thread on this topic (
> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for the
> release cadence and EOL. The proposal is as follows:
>
> "A minor release line is end-of-lifed 2 years after it is released or there
> are 2 newer minor releases, whichever is sooner. The community reserves the
> right to extend or shorten the life of a release line if there is a good
> reason to do so."
>
> This also entails that we the Hadoop community commit to following this
> practice and solving challenges to make it possible. Andrew Wang laid out
> some of those challenges and what can be done in the discussion thread
> mentioned above.
>
> I'll set the voting period to 7 days. I understand a majority rule would
> apply in this case. Your vote is greatly appreciated, and so are
> suggestions!
>
> Thanks,
> Sangjin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: [VOTE] Release cadence and EOL
Posted by Daniel Templeton <da...@cloudera.com>.
Thanks for driving this, Sangjin. Quick question, though: the subject
line is "Release cadence and EOL," but I don't see anything about
cadence in the proposal. Did I miss something?
Daniel
On 1/17/17 8:35 AM, Sangjin Lee wrote:
> Following up on the discussion thread on this topic (
> https://s.apache.org/eFOf), I'd like to put the proposal for a vote for the
> release cadence and EOL. The proposal is as follows:
>
> "A minor release line is end-of-lifed 2 years after it is released or there
> are 2 newer minor releases, whichever is sooner. The community reserves the
> right to extend or shorten the life of a release line if there is a good
> reason to do so."
>
> This also entails that we the Hadoop community commit to following this
> practice and solving challenges to make it possible. Andrew Wang laid out
> some of those challenges and what can be done in the discussion thread
> mentioned above.
>
> I'll set the voting period to 7 days. I understand a majority rule would
> apply in this case. Your vote is greatly appreciated, and so are
> suggestions!
>
> Thanks,
> Sangjin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org