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 <dan...@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-unsubscr...@hadoop.apache.org > > > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > > > > > > > > >
