Re: Make EOL branches to public?
I would also suggest making an explicit commit to the branch stating it is EOL. Thanks, --Konstantin On Tue, Aug 20, 2019 at 7:59 PM Wangda Tan wrote: > Thank you all for suggestions. Let me send a vote email to mark 2.6, 2.7, > 3.0 EOL. > > - Wangda > > On Wed, Aug 21, 2019 at 9:34 AM Akira Ajisaka wrote: > > > +1 > > > > Thank you for the discussion. > > > > -Akira > > > > On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang > > wrote: > > > > > > +1 > > > I feel like one year of inactivity is a good sign that the community is > > not > > > interested in the branch any more. > > > > > > On Fri, Aug 16, 2019 at 3:14 AM Wangda Tan > wrote: > > > > > > > Hi folks, > > > > > > > > Want to hear your thoughts about what we should do to make some > > branches > > > > EOL. We discussed a couple of times before in dev lists and PMC list. > > > > However, we couldn't get a formal process of EOL. According to the > > > > discussion. It is hard to decide it based on time like "After 1st > > release, > > > > EOL in 2 years". Because community members still want to maintain it > > and > > > > developers still want to get a newer version released. > > > > > > > > However, without a public place to figure out which release will be > > EOL, it > > > > is very hard for users to choose the right releases to upgrade and > > develop. > > > > > > > > So I want to propose to make an agreement about making a public EOL > > wiki > > > > page and create a process to EOL a release: > > > > > > > > The process I'm thinking is very simple: If no volunteer to do a > > > > maintenance release in a short to mid-term (like 3 months to 1 or 1.5 > > > > year). We will claim a release is EOL. After EOL community can still > > choose > > > > to do a security-only release. > > > > > > > > Here's a list which I can think about: > > > > > > > > 1) 2.6.x (Or any release older than 2.6) (Last released at Oct 2016) > > > > 2) 2.7.x (Last released at Apr 2018) > > > > 4) 3.0.x (Last released at May 2018) > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Wangda > > > > > > >
Re: Make EOL branches to public?
Thank you all for suggestions. Let me send a vote email to mark 2.6, 2.7, 3.0 EOL. - Wangda On Wed, Aug 21, 2019 at 9:34 AM Akira Ajisaka wrote: > +1 > > Thank you for the discussion. > > -Akira > > On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang > wrote: > > > > +1 > > I feel like one year of inactivity is a good sign that the community is > not > > interested in the branch any more. > > > > On Fri, Aug 16, 2019 at 3:14 AM Wangda Tan wrote: > > > > > Hi folks, > > > > > > Want to hear your thoughts about what we should do to make some > branches > > > EOL. We discussed a couple of times before in dev lists and PMC list. > > > However, we couldn't get a formal process of EOL. According to the > > > discussion. It is hard to decide it based on time like "After 1st > release, > > > EOL in 2 years". Because community members still want to maintain it > and > > > developers still want to get a newer version released. > > > > > > However, without a public place to figure out which release will be > EOL, it > > > is very hard for users to choose the right releases to upgrade and > develop. > > > > > > So I want to propose to make an agreement about making a public EOL > wiki > > > page and create a process to EOL a release: > > > > > > The process I'm thinking is very simple: If no volunteer to do a > > > maintenance release in a short to mid-term (like 3 months to 1 or 1.5 > > > year). We will claim a release is EOL. After EOL community can still > choose > > > to do a security-only release. > > > > > > Here's a list which I can think about: > > > > > > 1) 2.6.x (Or any release older than 2.6) (Last released at Oct 2016) > > > 2) 2.7.x (Last released at Apr 2018) > > > 4) 3.0.x (Last released at May 2018) > > > > > > Thoughts? > > > > > > Thanks, > > > Wangda > > > >
Re: Make EOL branches to public?
+1 Thank you for the discussion. -Akira On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang wrote: > > +1 > I feel like one year of inactivity is a good sign that the community is not > interested in the branch any more. > > On Fri, Aug 16, 2019 at 3:14 AM Wangda Tan wrote: > > > Hi folks, > > > > Want to hear your thoughts about what we should do to make some branches > > EOL. We discussed a couple of times before in dev lists and PMC list. > > However, we couldn't get a formal process of EOL. According to the > > discussion. It is hard to decide it based on time like "After 1st release, > > EOL in 2 years". Because community members still want to maintain it and > > developers still want to get a newer version released. > > > > However, without a public place to figure out which release will be EOL, it > > is very hard for users to choose the right releases to upgrade and develop. > > > > So I want to propose to make an agreement about making a public EOL wiki > > page and create a process to EOL a release: > > > > The process I'm thinking is very simple: If no volunteer to do a > > maintenance release in a short to mid-term (like 3 months to 1 or 1.5 > > year). We will claim a release is EOL. After EOL community can still choose > > to do a security-only release. > > > > Here's a list which I can think about: > > > > 1) 2.6.x (Or any release older than 2.6) (Last released at Oct 2016) > > 2) 2.7.x (Last released at Apr 2018) > > 4) 3.0.x (Last released at May 2018) > > > > Thoughts? > > > > Thanks, > > Wangda > > - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
Re: Make EOL branches to public?
+1 I feel like one year of inactivity is a good sign that the community is not interested in the branch any more. On Fri, Aug 16, 2019 at 3:14 AM Wangda Tan wrote: > Hi folks, > > Want to hear your thoughts about what we should do to make some branches > EOL. We discussed a couple of times before in dev lists and PMC list. > However, we couldn't get a formal process of EOL. According to the > discussion. It is hard to decide it based on time like "After 1st release, > EOL in 2 years". Because community members still want to maintain it and > developers still want to get a newer version released. > > However, without a public place to figure out which release will be EOL, it > is very hard for users to choose the right releases to upgrade and develop. > > So I want to propose to make an agreement about making a public EOL wiki > page and create a process to EOL a release: > > The process I'm thinking is very simple: If no volunteer to do a > maintenance release in a short to mid-term (like 3 months to 1 or 1.5 > year). We will claim a release is EOL. After EOL community can still choose > to do a security-only release. > > Here's a list which I can think about: > > 1) 2.6.x (Or any release older than 2.6) (Last released at Oct 2016) > 2) 2.7.x (Last released at Apr 2018) > 4) 3.0.x (Last released at May 2018) > > Thoughts? > > Thanks, > Wangda >
Re: Make EOL branches to public?
For what it's worth, in HBase we've been approximating which Hadoop lines are EOL by looking at release rates and specifically CVE announcements that include an affected release line but do not include a fix for that release line. Our current approximation[1] lists 2.6, 2.7, and 3.0 as dead. So that lines up well with your proposed list. [1]: http://hbase.apache.org/book.html#hadoop On Fri, Aug 16, 2019 at 5:14 AM Wangda Tan wrote: > > Hi folks, > > Want to hear your thoughts about what we should do to make some branches > EOL. We discussed a couple of times before in dev lists and PMC list. > However, we couldn't get a formal process of EOL. According to the > discussion. It is hard to decide it based on time like "After 1st release, > EOL in 2 years". Because community members still want to maintain it and > developers still want to get a newer version released. > > However, without a public place to figure out which release will be EOL, it > is very hard for users to choose the right releases to upgrade and develop. > > So I want to propose to make an agreement about making a public EOL wiki > page and create a process to EOL a release: > > The process I'm thinking is very simple: If no volunteer to do a > maintenance release in a short to mid-term (like 3 months to 1 or 1.5 > year). We will claim a release is EOL. After EOL community can still choose > to do a security-only release. > > Here's a list which I can think about: > > 1) 2.6.x (Or any release older than 2.6) (Last released at Oct 2016) > 2) 2.7.x (Last released at Apr 2018) > 4) 3.0.x (Last released at May 2018) > > Thoughts? > > Thanks, > Wangda -- busbey - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
