You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by Wangda Tan <wh...@gmail.com> on 2019/08/16 10:14:15 UTC
Make EOL branches to public?
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?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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 <wh...@gmail.com> 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 <aa...@apache.org> wrote:
>
> > +1
> >
> > Thank you for the discussion.
> >
> > -Akira
> >
> > On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org>
> > 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 <wh...@gmail.com>
> 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?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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 <wh...@gmail.com> 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 <aa...@apache.org> wrote:
>
> > +1
> >
> > Thank you for the discussion.
> >
> > -Akira
> >
> > On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org>
> > 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 <wh...@gmail.com>
> 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?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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 <wh...@gmail.com> 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 <aa...@apache.org> wrote:
>
> > +1
> >
> > Thank you for the discussion.
> >
> > -Akira
> >
> > On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org>
> > 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 <wh...@gmail.com>
> 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?
Posted by Konstantin Shvachko <sh...@gmail.com>.
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 <wh...@gmail.com> 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 <aa...@apache.org> wrote:
>
> > +1
> >
> > Thank you for the discussion.
> >
> > -Akira
> >
> > On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org>
> > 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 <wh...@gmail.com>
> 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?
Posted by Wangda Tan <wh...@gmail.com>.
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 <aa...@apache.org> wrote:
> +1
>
> Thank you for the discussion.
>
> -Akira
>
> On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org>
> 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 <wh...@gmail.com> 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?
Posted by Wangda Tan <wh...@gmail.com>.
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 <aa...@apache.org> wrote:
> +1
>
> Thank you for the discussion.
>
> -Akira
>
> On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org>
> 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 <wh...@gmail.com> 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?
Posted by Wangda Tan <wh...@gmail.com>.
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 <aa...@apache.org> wrote:
> +1
>
> Thank you for the discussion.
>
> -Akira
>
> On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org>
> 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 <wh...@gmail.com> 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?
Posted by Wangda Tan <wh...@gmail.com>.
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 <aa...@apache.org> wrote:
> +1
>
> Thank you for the discussion.
>
> -Akira
>
> On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org>
> 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 <wh...@gmail.com> 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?
Posted by Akira Ajisaka <aa...@apache.org>.
+1
Thank you for the discussion.
-Akira
On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org> 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 <wh...@gmail.com> 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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Make EOL branches to public?
Posted by Akira Ajisaka <aa...@apache.org>.
+1
Thank you for the discussion.
-Akira
On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org> 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 <wh...@gmail.com> 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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Make EOL branches to public?
Posted by Akira Ajisaka <aa...@apache.org>.
+1
Thank you for the discussion.
-Akira
On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org> 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 <wh...@gmail.com> 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: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Make EOL branches to public?
Posted by Akira Ajisaka <aa...@apache.org>.
+1
Thank you for the discussion.
-Akira
On Wed, Aug 21, 2019 at 5:51 AM Wei-Chiu Chuang <we...@apache.org> 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 <wh...@gmail.com> 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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org
Re: Make EOL branches to public?
Posted by Wei-Chiu Chuang <we...@apache.org>.
+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 <wh...@gmail.com> 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?
Posted by Wei-Chiu Chuang <we...@apache.org>.
+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 <wh...@gmail.com> 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?
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
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 <wh...@gmail.com> 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: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org
Re: Make EOL branches to public?
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
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 <wh...@gmail.com> 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: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org
Re: Make EOL branches to public?
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
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 <wh...@gmail.com> 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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org
Re: Make EOL branches to public?
Posted by Wei-Chiu Chuang <we...@apache.org>.
+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 <wh...@gmail.com> 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?
Posted by Wei-Chiu Chuang <we...@apache.org>.
+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 <wh...@gmail.com> 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?
Posted by Sean Busbey <bu...@cloudera.com.INVALID>.
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 <wh...@gmail.com> 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: hdfs-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org