EOL branch-1 and all 1.x ?

[Andrew Purtell <ap...@apache.org>]

Is it time to consider EOL of branch-1 and all 1.x releases ?

There doesn't seem to be much developer interest in branch-1 beyond
occasional maintenance. This is understandable. Per our compatibility
guidelines, branch-1 commits must be compatible with Java 7, and the range
of acceptable versions of third party dependencies is also restricted due
to Java 7 compatibility requirements. Most developers are writing code with
Java 8+ idioms these days. For that reason and because the branch-1 code
base is generally aged at this point, all but trivial (or lucky!) backports
require substantial changes in order to integrate adequately. Let me also
observe that branch-1 artifacts are not fully compatible with Java 11 or
later. (The shell is a good example of such issues: The version of
jruby-complete required by branch-1 is not compatible with Java 11 and
upgrading to the version used by branch-2 causes shell commands to error
out due to Ruby language changes.)

We can a priori determine there is insufficient motivation for production
of release artifacts for the PMC to vote upon. Otherwise, someone would
have done it. We had 12 releases from branch-2 derived code in 2019, 13
releases from branch-2 derived code in 2020, and so far we have had 3
releases from branch-2 derived code in 2021. In contrast, we had 8 releases
from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
so far 0 releases from branch-1 in 2021.

*  2021202020191.x0282.x31312*

If there is someone interested in continuing branch-1, now is the time to
commit. However let me be clear that simply expressing an abstract desire
to see continued branch-1 releases will not be that useful. It will be
noted, but will not have much real world impact. Apache is a do-ocracy. In
the absence of intrinsic motivation of project participants, which is what
we seem to have here, you will need to do something: Fix the compatibility
issues, if any between the last release of 1.x and the current branch-1
head; fix any failing and flaky unit tests; produce release artifacts; and
submit those artifacts to the PMC for voting. Or, convince someone with
commit rights and/or PMC membership to undertake these actions on your
behalf.

Otherwise, I respectfully submit for your consideration, it is time to
declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
effectively already happened.

-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: EOL branch-1 and all 1.x ?

[Reid Chan <re...@gmail.com>]

+1 for EOL branch-1.4

Thanks for the works

On Wed, Oct 13, 2021 at 1:39 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Filed HBASE-26355 for releasing 1.4.14.
>
> 张铎(Duo Zhang) <pa...@gmail.com> 于2021年10月11日周一 下午5:31写道：
>
> > So I think in this thread, the only concern is about performance issues,
> > so we decided to make new releases on branch-1.
> >
> > But at least I think we all agree to EOL other 1.x release lines,
> > especially branch-1.4 right?
> >
> > If no other concerns, let's do a final 1.4.14 release and then mark
> > branch-1.4 as EOL. There are 40 issues under 1.4.14 so I think it is
> worth
> > having a new release.
> >
> > Thanks.
> >
> > Andrew Purtell <an...@gmail.com> 于2021年6月1日周二 上午3:16写道：
> >
> >> It would be good to do the performance work at least, if you are up for
> >> it. There are always going to be consequences for the kind of
> significant
> >> evolution that 2.x represents over 1.x.
> >>
> >> Regarding performance, a change always has positive and negative
> >> consequences. It is important to understand them both, informed by real
> >> world use cases. My guess is you have real world use cases, Reid. Your
> >> results will be meaningful.
> >>
> >> Synthetic benchmarks are less interesting unless the regression is
> >> obvious and more like a bug than a consequence. Sure they will report
> >> positive and negative changes, but does that actually mean anything? It
> >> depends. Sometimes it will only mean something if we care about
> supporting
> >> the synthetic benchmark as a first class use case. (Usually we don’t;
> but
> >> universal cross system bench tools like YCSB are exceptions.)
> >>
> >>
> >> > On May 31, 2021, at 9:25 AM, Reid Chan <re...@gmail.com>
> wrote:
> >> >
> >> > Thanks to Andrew and Sean's help, I managed to release the first
> >> candidate
> >> > of 1.7.0 (at least it is a beginning, and graduated from green hand).
> >> > BTW, The [VOTE]
> >> > <
> >>
> https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E
> >> >
> >> >
> >> > The following are my thoughts:
> >> > I'm willing to continue branch-1's life as a RM.
> >> > And before EOL branch-1, I need to announce EOL of branch-1.4.
> >> > While maintaining the branch-1, I also will do some benchmarks between
> >> 1.7+
> >> > and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing
> >> to
> >> > spend some time diving in.
> >> > After the performance issue is done, I need to review the upgrade from
> >> 1.x
> >> > to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal
> >> some
> >> > problems already.
> >> > I will announce EOL of branch-1 if listed above are done.
> >> >
> >> > Probably more than 1 year, by estimation, if I have to do it all
> alone.
> >> The
> >> > most time-spending should be performance diving in (if there was) and
> >> > upgrade review.
> >> >
> >> > Any thought is appreciated.
> >> >
> >> >
> >> > ---
> >> > Best regards,
> >> > R.C
> >> >
> >> >
> >> >
> >> >
> >> >> On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com>
> >> wrote:
> >> >>
> >> >>
> >> >> FYI, a JDK issue when I was making the 1.7.0 release.
> >> >>
> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
> >> >>
> >> >>
> >> >> ---
> >> >> Best Regards,
> >> >> R.C
> >> >>
> >> >>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
> >> wrote:
> >> >>>
> >> >>> Is it time to consider EOL of branch-1 and all 1.x releases ?
> >> >>>
> >> >>> There doesn't seem to be much developer interest in branch-1 beyond
> >> >>> occasional maintenance. This is understandable. Per our
> compatibility
> >> >>> guidelines, branch-1 commits must be compatible with Java 7, and the
> >> range
> >> >>> of acceptable versions of third party dependencies is also
> restricted
> >> due
> >> >>> to Java 7 compatibility requirements. Most developers are writing
> code
> >> >>> with
> >> >>> Java 8+ idioms these days. For that reason and because the branch-1
> >> code
> >> >>> base is generally aged at this point, all but trivial (or lucky!)
> >> >>> backports
> >> >>> require substantial changes in order to integrate adequately. Let me
> >> also
> >> >>> observe that branch-1 artifacts are not fully compatible with Java
> 11
> >> or
> >> >>> later. (The shell is a good example of such issues: The version of
> >> >>> jruby-complete required by branch-1 is not compatible with Java 11
> and
> >> >>> upgrading to the version used by branch-2 causes shell commands to
> >> error
> >> >>> out due to Ruby language changes.)
> >> >>>
> >> >>> We can a priori determine there is insufficient motivation for
> >> production
> >> >>> of release artifacts for the PMC to vote upon. Otherwise, someone
> >> would
> >> >>> have done it. We had 12 releases from branch-2 derived code in 2019,
> >> 13
> >> >>> releases from branch-2 derived code in 2020, and so far we have had
> 3
> >> >>> releases from branch-2 derived code in 2021. In contrast, we had 8
> >> >>> releases
> >> >>> from branch-1 derived code in 2019, 0 releases from branch-1 in
> 2020,
> >> and
> >> >>> so far 0 releases from branch-1 in 2021.
> >> >>>
> >> >>> *  2021202020191.x0282.x31312*
> >> >>>
> >> >>> If there is someone interested in continuing branch-1, now is the
> >> time to
> >> >>> commit. However let me be clear that simply expressing an abstract
> >> desire
> >> >>> to see continued branch-1 releases will not be that useful. It will
> be
> >> >>> noted, but will not have much real world impact. Apache is a
> >> do-ocracy. In
> >> >>> the absence of intrinsic motivation of project participants, which
> is
> >> what
> >> >>> we seem to have here, you will need to do something: Fix the
> >> compatibility
> >> >>> issues, if any between the last release of 1.x and the current
> >> branch-1
> >> >>> head; fix any failing and flaky unit tests; produce release
> >> artifacts; and
> >> >>> submit those artifacts to the PMC for voting. Or, convince someone
> >> with
> >> >>> commit rights and/or PMC membership to undertake these actions on
> your
> >> >>> behalf.
> >> >>>
> >> >>> Otherwise, I respectfully submit for your consideration, it is time
> to
> >> >>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging
> >> what
> >> >>> has
> >> >>> effectively already happened.
> >> >>>
> >> >>> --
> >> >>> Best regards,
> >> >>> Andrew
> >> >>>
> >> >>> Words like orphans lost among the crosstalk, meaning torn from
> truth's
> >> >>> decrepit hands
> >> >>>   - A23, Crosstalk
> >> >>>
> >> >>
> >>
> >
>

Re: EOL branch-1 and all 1.x ?

[Reid Chan <re...@gmail.com>]

+1 for EOL branch-1.4

Thanks for the works

On Wed, Oct 13, 2021 at 1:39 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Filed HBASE-26355 for releasing 1.4.14.
>
> 张铎(Duo Zhang) <pa...@gmail.com> 于2021年10月11日周一 下午5:31写道：
>
> > So I think in this thread, the only concern is about performance issues,
> > so we decided to make new releases on branch-1.
> >
> > But at least I think we all agree to EOL other 1.x release lines,
> > especially branch-1.4 right?
> >
> > If no other concerns, let's do a final 1.4.14 release and then mark
> > branch-1.4 as EOL. There are 40 issues under 1.4.14 so I think it is
> worth
> > having a new release.
> >
> > Thanks.
> >
> > Andrew Purtell <an...@gmail.com> 于2021年6月1日周二 上午3:16写道：
> >
> >> It would be good to do the performance work at least, if you are up for
> >> it. There are always going to be consequences for the kind of
> significant
> >> evolution that 2.x represents over 1.x.
> >>
> >> Regarding performance, a change always has positive and negative
> >> consequences. It is important to understand them both, informed by real
> >> world use cases. My guess is you have real world use cases, Reid. Your
> >> results will be meaningful.
> >>
> >> Synthetic benchmarks are less interesting unless the regression is
> >> obvious and more like a bug than a consequence. Sure they will report
> >> positive and negative changes, but does that actually mean anything? It
> >> depends. Sometimes it will only mean something if we care about
> supporting
> >> the synthetic benchmark as a first class use case. (Usually we don’t;
> but
> >> universal cross system bench tools like YCSB are exceptions.)
> >>
> >>
> >> > On May 31, 2021, at 9:25 AM, Reid Chan <re...@gmail.com>
> wrote:
> >> >
> >> > Thanks to Andrew and Sean's help, I managed to release the first
> >> candidate
> >> > of 1.7.0 (at least it is a beginning, and graduated from green hand).
> >> > BTW, The [VOTE]
> >> > <
> >>
> https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E
> >> >
> >> >
> >> > The following are my thoughts:
> >> > I'm willing to continue branch-1's life as a RM.
> >> > And before EOL branch-1, I need to announce EOL of branch-1.4.
> >> > While maintaining the branch-1, I also will do some benchmarks between
> >> 1.7+
> >> > and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing
> >> to
> >> > spend some time diving in.
> >> > After the performance issue is done, I need to review the upgrade from
> >> 1.x
> >> > to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal
> >> some
> >> > problems already.
> >> > I will announce EOL of branch-1 if listed above are done.
> >> >
> >> > Probably more than 1 year, by estimation, if I have to do it all
> alone.
> >> The
> >> > most time-spending should be performance diving in (if there was) and
> >> > upgrade review.
> >> >
> >> > Any thought is appreciated.
> >> >
> >> >
> >> > ---
> >> > Best regards,
> >> > R.C
> >> >
> >> >
> >> >
> >> >
> >> >> On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com>
> >> wrote:
> >> >>
> >> >>
> >> >> FYI, a JDK issue when I was making the 1.7.0 release.
> >> >>
> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
> >> >>
> >> >>
> >> >> ---
> >> >> Best Regards,
> >> >> R.C
> >> >>
> >> >>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
> >> wrote:
> >> >>>
> >> >>> Is it time to consider EOL of branch-1 and all 1.x releases ?
> >> >>>
> >> >>> There doesn't seem to be much developer interest in branch-1 beyond
> >> >>> occasional maintenance. This is understandable. Per our
> compatibility
> >> >>> guidelines, branch-1 commits must be compatible with Java 7, and the
> >> range
> >> >>> of acceptable versions of third party dependencies is also
> restricted
> >> due
> >> >>> to Java 7 compatibility requirements. Most developers are writing
> code
> >> >>> with
> >> >>> Java 8+ idioms these days. For that reason and because the branch-1
> >> code
> >> >>> base is generally aged at this point, all but trivial (or lucky!)
> >> >>> backports
> >> >>> require substantial changes in order to integrate adequately. Let me
> >> also
> >> >>> observe that branch-1 artifacts are not fully compatible with Java
> 11
> >> or
> >> >>> later. (The shell is a good example of such issues: The version of
> >> >>> jruby-complete required by branch-1 is not compatible with Java 11
> and
> >> >>> upgrading to the version used by branch-2 causes shell commands to
> >> error
> >> >>> out due to Ruby language changes.)
> >> >>>
> >> >>> We can a priori determine there is insufficient motivation for
> >> production
> >> >>> of release artifacts for the PMC to vote upon. Otherwise, someone
> >> would
> >> >>> have done it. We had 12 releases from branch-2 derived code in 2019,
> >> 13
> >> >>> releases from branch-2 derived code in 2020, and so far we have had
> 3
> >> >>> releases from branch-2 derived code in 2021. In contrast, we had 8
> >> >>> releases
> >> >>> from branch-1 derived code in 2019, 0 releases from branch-1 in
> 2020,
> >> and
> >> >>> so far 0 releases from branch-1 in 2021.
> >> >>>
> >> >>> *  2021202020191.x0282.x31312*
> >> >>>
> >> >>> If there is someone interested in continuing branch-1, now is the
> >> time to
> >> >>> commit. However let me be clear that simply expressing an abstract
> >> desire
> >> >>> to see continued branch-1 releases will not be that useful. It will
> be
> >> >>> noted, but will not have much real world impact. Apache is a
> >> do-ocracy. In
> >> >>> the absence of intrinsic motivation of project participants, which
> is
> >> what
> >> >>> we seem to have here, you will need to do something: Fix the
> >> compatibility
> >> >>> issues, if any between the last release of 1.x and the current
> >> branch-1
> >> >>> head; fix any failing and flaky unit tests; produce release
> >> artifacts; and
> >> >>> submit those artifacts to the PMC for voting. Or, convince someone
> >> with
> >> >>> commit rights and/or PMC membership to undertake these actions on
> your
> >> >>> behalf.
> >> >>>
> >> >>> Otherwise, I respectfully submit for your consideration, it is time
> to
> >> >>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging
> >> what
> >> >>> has
> >> >>> effectively already happened.
> >> >>>
> >> >>> --
> >> >>> Best regards,
> >> >>> Andrew
> >> >>>
> >> >>> Words like orphans lost among the crosstalk, meaning torn from
> truth's
> >> >>> decrepit hands
> >> >>>   - A23, Crosstalk
> >> >>>
> >> >>
> >>
> >
>

Re: EOL branch-1 and all 1.x ?

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Filed HBASE-26355 for releasing 1.4.14.

张铎(Duo Zhang) <pa...@gmail.com> 于2021年10月11日周一 下午5:31写道：

> So I think in this thread, the only concern is about performance issues,
> so we decided to make new releases on branch-1.
>
> But at least I think we all agree to EOL other 1.x release lines,
> especially branch-1.4 right?
>
> If no other concerns, let's do a final 1.4.14 release and then mark
> branch-1.4 as EOL. There are 40 issues under 1.4.14 so I think it is worth
> having a new release.
>
> Thanks.
>
> Andrew Purtell <an...@gmail.com> 于2021年6月1日周二 上午3:16写道：
>
>> It would be good to do the performance work at least, if you are up for
>> it. There are always going to be consequences for the kind of significant
>> evolution that 2.x represents over 1.x.
>>
>> Regarding performance, a change always has positive and negative
>> consequences. It is important to understand them both, informed by real
>> world use cases. My guess is you have real world use cases, Reid. Your
>> results will be meaningful.
>>
>> Synthetic benchmarks are less interesting unless the regression is
>> obvious and more like a bug than a consequence. Sure they will report
>> positive and negative changes, but does that actually mean anything? It
>> depends. Sometimes it will only mean something if we care about supporting
>> the synthetic benchmark as a first class use case. (Usually we don’t; but
>> universal cross system bench tools like YCSB are exceptions.)
>>
>>
>> > On May 31, 2021, at 9:25 AM, Reid Chan <re...@gmail.com> wrote:
>> >
>> > Thanks to Andrew and Sean's help, I managed to release the first
>> candidate
>> > of 1.7.0 (at least it is a beginning, and graduated from green hand).
>> > BTW, The [VOTE]
>> > <
>> https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E
>> >
>> >
>> > The following are my thoughts:
>> > I'm willing to continue branch-1's life as a RM.
>> > And before EOL branch-1, I need to announce EOL of branch-1.4.
>> > While maintaining the branch-1, I also will do some benchmarks between
>> 1.7+
>> > and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing
>> to
>> > spend some time diving in.
>> > After the performance issue is done, I need to review the upgrade from
>> 1.x
>> > to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal
>> some
>> > problems already.
>> > I will announce EOL of branch-1 if listed above are done.
>> >
>> > Probably more than 1 year, by estimation, if I have to do it all alone.
>> The
>> > most time-spending should be performance diving in (if there was) and
>> > upgrade review.
>> >
>> > Any thought is appreciated.
>> >
>> >
>> > ---
>> > Best regards,
>> > R.C
>> >
>> >
>> >
>> >
>> >> On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com>
>> wrote:
>> >>
>> >>
>> >> FYI, a JDK issue when I was making the 1.7.0 release.
>> >>
>> >>
>> >>
>> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
>> >>
>> >>
>> >> ---
>> >> Best Regards,
>> >> R.C
>> >>
>> >>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
>> wrote:
>> >>>
>> >>> Is it time to consider EOL of branch-1 and all 1.x releases ?
>> >>>
>> >>> There doesn't seem to be much developer interest in branch-1 beyond
>> >>> occasional maintenance. This is understandable. Per our compatibility
>> >>> guidelines, branch-1 commits must be compatible with Java 7, and the
>> range
>> >>> of acceptable versions of third party dependencies is also restricted
>> due
>> >>> to Java 7 compatibility requirements. Most developers are writing code
>> >>> with
>> >>> Java 8+ idioms these days. For that reason and because the branch-1
>> code
>> >>> base is generally aged at this point, all but trivial (or lucky!)
>> >>> backports
>> >>> require substantial changes in order to integrate adequately. Let me
>> also
>> >>> observe that branch-1 artifacts are not fully compatible with Java 11
>> or
>> >>> later. (The shell is a good example of such issues: The version of
>> >>> jruby-complete required by branch-1 is not compatible with Java 11 and
>> >>> upgrading to the version used by branch-2 causes shell commands to
>> error
>> >>> out due to Ruby language changes.)
>> >>>
>> >>> We can a priori determine there is insufficient motivation for
>> production
>> >>> of release artifacts for the PMC to vote upon. Otherwise, someone
>> would
>> >>> have done it. We had 12 releases from branch-2 derived code in 2019,
>> 13
>> >>> releases from branch-2 derived code in 2020, and so far we have had 3
>> >>> releases from branch-2 derived code in 2021. In contrast, we had 8
>> >>> releases
>> >>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
>> and
>> >>> so far 0 releases from branch-1 in 2021.
>> >>>
>> >>> *  2021202020191.x0282.x31312*
>> >>>
>> >>> If there is someone interested in continuing branch-1, now is the
>> time to
>> >>> commit. However let me be clear that simply expressing an abstract
>> desire
>> >>> to see continued branch-1 releases will not be that useful. It will be
>> >>> noted, but will not have much real world impact. Apache is a
>> do-ocracy. In
>> >>> the absence of intrinsic motivation of project participants, which is
>> what
>> >>> we seem to have here, you will need to do something: Fix the
>> compatibility
>> >>> issues, if any between the last release of 1.x and the current
>> branch-1
>> >>> head; fix any failing and flaky unit tests; produce release
>> artifacts; and
>> >>> submit those artifacts to the PMC for voting. Or, convince someone
>> with
>> >>> commit rights and/or PMC membership to undertake these actions on your
>> >>> behalf.
>> >>>
>> >>> Otherwise, I respectfully submit for your consideration, it is time to
>> >>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging
>> what
>> >>> has
>> >>> effectively already happened.
>> >>>
>> >>> --
>> >>> Best regards,
>> >>> Andrew
>> >>>
>> >>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> >>> decrepit hands
>> >>>   - A23, Crosstalk
>> >>>
>> >>
>>
>

Re: EOL branch-1 and all 1.x ?

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Filed HBASE-26355 for releasing 1.4.14.

张铎(Duo Zhang) <pa...@gmail.com> 于2021年10月11日周一 下午5:31写道：

> So I think in this thread, the only concern is about performance issues,
> so we decided to make new releases on branch-1.
>
> But at least I think we all agree to EOL other 1.x release lines,
> especially branch-1.4 right?
>
> If no other concerns, let's do a final 1.4.14 release and then mark
> branch-1.4 as EOL. There are 40 issues under 1.4.14 so I think it is worth
> having a new release.
>
> Thanks.
>
> Andrew Purtell <an...@gmail.com> 于2021年6月1日周二 上午3:16写道：
>
>> It would be good to do the performance work at least, if you are up for
>> it. There are always going to be consequences for the kind of significant
>> evolution that 2.x represents over 1.x.
>>
>> Regarding performance, a change always has positive and negative
>> consequences. It is important to understand them both, informed by real
>> world use cases. My guess is you have real world use cases, Reid. Your
>> results will be meaningful.
>>
>> Synthetic benchmarks are less interesting unless the regression is
>> obvious and more like a bug than a consequence. Sure they will report
>> positive and negative changes, but does that actually mean anything? It
>> depends. Sometimes it will only mean something if we care about supporting
>> the synthetic benchmark as a first class use case. (Usually we don’t; but
>> universal cross system bench tools like YCSB are exceptions.)
>>
>>
>> > On May 31, 2021, at 9:25 AM, Reid Chan <re...@gmail.com> wrote:
>> >
>> > Thanks to Andrew and Sean's help, I managed to release the first
>> candidate
>> > of 1.7.0 (at least it is a beginning, and graduated from green hand).
>> > BTW, The [VOTE]
>> > <
>> https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E
>> >
>> >
>> > The following are my thoughts:
>> > I'm willing to continue branch-1's life as a RM.
>> > And before EOL branch-1, I need to announce EOL of branch-1.4.
>> > While maintaining the branch-1, I also will do some benchmarks between
>> 1.7+
>> > and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing
>> to
>> > spend some time diving in.
>> > After the performance issue is done, I need to review the upgrade from
>> 1.x
>> > to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal
>> some
>> > problems already.
>> > I will announce EOL of branch-1 if listed above are done.
>> >
>> > Probably more than 1 year, by estimation, if I have to do it all alone.
>> The
>> > most time-spending should be performance diving in (if there was) and
>> > upgrade review.
>> >
>> > Any thought is appreciated.
>> >
>> >
>> > ---
>> > Best regards,
>> > R.C
>> >
>> >
>> >
>> >
>> >> On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com>
>> wrote:
>> >>
>> >>
>> >> FYI, a JDK issue when I was making the 1.7.0 release.
>> >>
>> >>
>> >>
>> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
>> >>
>> >>
>> >> ---
>> >> Best Regards,
>> >> R.C
>> >>
>> >>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
>> wrote:
>> >>>
>> >>> Is it time to consider EOL of branch-1 and all 1.x releases ?
>> >>>
>> >>> There doesn't seem to be much developer interest in branch-1 beyond
>> >>> occasional maintenance. This is understandable. Per our compatibility
>> >>> guidelines, branch-1 commits must be compatible with Java 7, and the
>> range
>> >>> of acceptable versions of third party dependencies is also restricted
>> due
>> >>> to Java 7 compatibility requirements. Most developers are writing code
>> >>> with
>> >>> Java 8+ idioms these days. For that reason and because the branch-1
>> code
>> >>> base is generally aged at this point, all but trivial (or lucky!)
>> >>> backports
>> >>> require substantial changes in order to integrate adequately. Let me
>> also
>> >>> observe that branch-1 artifacts are not fully compatible with Java 11
>> or
>> >>> later. (The shell is a good example of such issues: The version of
>> >>> jruby-complete required by branch-1 is not compatible with Java 11 and
>> >>> upgrading to the version used by branch-2 causes shell commands to
>> error
>> >>> out due to Ruby language changes.)
>> >>>
>> >>> We can a priori determine there is insufficient motivation for
>> production
>> >>> of release artifacts for the PMC to vote upon. Otherwise, someone
>> would
>> >>> have done it. We had 12 releases from branch-2 derived code in 2019,
>> 13
>> >>> releases from branch-2 derived code in 2020, and so far we have had 3
>> >>> releases from branch-2 derived code in 2021. In contrast, we had 8
>> >>> releases
>> >>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
>> and
>> >>> so far 0 releases from branch-1 in 2021.
>> >>>
>> >>> *  2021202020191.x0282.x31312*
>> >>>
>> >>> If there is someone interested in continuing branch-1, now is the
>> time to
>> >>> commit. However let me be clear that simply expressing an abstract
>> desire
>> >>> to see continued branch-1 releases will not be that useful. It will be
>> >>> noted, but will not have much real world impact. Apache is a
>> do-ocracy. In
>> >>> the absence of intrinsic motivation of project participants, which is
>> what
>> >>> we seem to have here, you will need to do something: Fix the
>> compatibility
>> >>> issues, if any between the last release of 1.x and the current
>> branch-1
>> >>> head; fix any failing and flaky unit tests; produce release
>> artifacts; and
>> >>> submit those artifacts to the PMC for voting. Or, convince someone
>> with
>> >>> commit rights and/or PMC membership to undertake these actions on your
>> >>> behalf.
>> >>>
>> >>> Otherwise, I respectfully submit for your consideration, it is time to
>> >>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging
>> what
>> >>> has
>> >>> effectively already happened.
>> >>>
>> >>> --
>> >>> Best regards,
>> >>> Andrew
>> >>>
>> >>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> >>> decrepit hands
>> >>>   - A23, Crosstalk
>> >>>
>> >>
>>
>

Re: EOL branch-1 and all 1.x ?

["张铎 (Duo Zhang)" <pa...@gmail.com>]

So I think in this thread, the only concern is about performance issues, so
we decided to make new releases on branch-1.

But at least I think we all agree to EOL other 1.x release lines,
especially branch-1.4 right?

If no other concerns, let's do a final 1.4.14 release and then mark
branch-1.4 as EOL. There are 40 issues under 1.4.14 so I think it is worth
having a new release.

Thanks.

Andrew Purtell <an...@gmail.com> 于2021年6月1日周二 上午3:16写道：

> It would be good to do the performance work at least, if you are up for
> it. There are always going to be consequences for the kind of significant
> evolution that 2.x represents over 1.x.
>
> Regarding performance, a change always has positive and negative
> consequences. It is important to understand them both, informed by real
> world use cases. My guess is you have real world use cases, Reid. Your
> results will be meaningful.
>
> Synthetic benchmarks are less interesting unless the regression is obvious
> and more like a bug than a consequence. Sure they will report positive and
> negative changes, but does that actually mean anything? It depends.
> Sometimes it will only mean something if we care about supporting the
> synthetic benchmark as a first class use case. (Usually we don’t; but
> universal cross system bench tools like YCSB are exceptions.)
>
>
> > On May 31, 2021, at 9:25 AM, Reid Chan <re...@gmail.com> wrote:
> >
> > Thanks to Andrew and Sean's help, I managed to release the first
> candidate
> > of 1.7.0 (at least it is a beginning, and graduated from green hand).
> > BTW, The [VOTE]
> > <
> https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E
> >
> >
> > The following are my thoughts:
> > I'm willing to continue branch-1's life as a RM.
> > And before EOL branch-1, I need to announce EOL of branch-1.4.
> > While maintaining the branch-1, I also will do some benchmarks between
> 1.7+
> > and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing to
> > spend some time diving in.
> > After the performance issue is done, I need to review the upgrade from
> 1.x
> > to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal some
> > problems already.
> > I will announce EOL of branch-1 if listed above are done.
> >
> > Probably more than 1 year, by estimation, if I have to do it all alone.
> The
> > most time-spending should be performance diving in (if there was) and
> > upgrade review.
> >
> > Any thought is appreciated.
> >
> >
> > ---
> > Best regards,
> > R.C
> >
> >
> >
> >
> >> On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com>
> wrote:
> >>
> >>
> >> FYI, a JDK issue when I was making the 1.7.0 release.
> >>
> >>
> >>
> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
> >>
> >>
> >> ---
> >> Best Regards,
> >> R.C
> >>
> >>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
> wrote:
> >>>
> >>> Is it time to consider EOL of branch-1 and all 1.x releases ?
> >>>
> >>> There doesn't seem to be much developer interest in branch-1 beyond
> >>> occasional maintenance. This is understandable. Per our compatibility
> >>> guidelines, branch-1 commits must be compatible with Java 7, and the
> range
> >>> of acceptable versions of third party dependencies is also restricted
> due
> >>> to Java 7 compatibility requirements. Most developers are writing code
> >>> with
> >>> Java 8+ idioms these days. For that reason and because the branch-1
> code
> >>> base is generally aged at this point, all but trivial (or lucky!)
> >>> backports
> >>> require substantial changes in order to integrate adequately. Let me
> also
> >>> observe that branch-1 artifacts are not fully compatible with Java 11
> or
> >>> later. (The shell is a good example of such issues: The version of
> >>> jruby-complete required by branch-1 is not compatible with Java 11 and
> >>> upgrading to the version used by branch-2 causes shell commands to
> error
> >>> out due to Ruby language changes.)
> >>>
> >>> We can a priori determine there is insufficient motivation for
> production
> >>> of release artifacts for the PMC to vote upon. Otherwise, someone would
> >>> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> >>> releases from branch-2 derived code in 2020, and so far we have had 3
> >>> releases from branch-2 derived code in 2021. In contrast, we had 8
> >>> releases
> >>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> and
> >>> so far 0 releases from branch-1 in 2021.
> >>>
> >>> *  2021202020191.x0282.x31312*
> >>>
> >>> If there is someone interested in continuing branch-1, now is the time
> to
> >>> commit. However let me be clear that simply expressing an abstract
> desire
> >>> to see continued branch-1 releases will not be that useful. It will be
> >>> noted, but will not have much real world impact. Apache is a
> do-ocracy. In
> >>> the absence of intrinsic motivation of project participants, which is
> what
> >>> we seem to have here, you will need to do something: Fix the
> compatibility
> >>> issues, if any between the last release of 1.x and the current branch-1
> >>> head; fix any failing and flaky unit tests; produce release artifacts;
> and
> >>> submit those artifacts to the PMC for voting. Or, convince someone with
> >>> commit rights and/or PMC membership to undertake these actions on your
> >>> behalf.
> >>>
> >>> Otherwise, I respectfully submit for your consideration, it is time to
> >>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
> >>> has
> >>> effectively already happened.
> >>>
> >>> --
> >>> Best regards,
> >>> Andrew
> >>>
> >>> Words like orphans lost among the crosstalk, meaning torn from truth's
> >>> decrepit hands
> >>>   - A23, Crosstalk
> >>>
> >>
>

Re: EOL branch-1 and all 1.x ?

["张铎 (Duo Zhang)" <pa...@gmail.com>]

So I think in this thread, the only concern is about performance issues, so
we decided to make new releases on branch-1.

But at least I think we all agree to EOL other 1.x release lines,
especially branch-1.4 right?

If no other concerns, let's do a final 1.4.14 release and then mark
branch-1.4 as EOL. There are 40 issues under 1.4.14 so I think it is worth
having a new release.

Thanks.

Andrew Purtell <an...@gmail.com> 于2021年6月1日周二 上午3:16写道：

> It would be good to do the performance work at least, if you are up for
> it. There are always going to be consequences for the kind of significant
> evolution that 2.x represents over 1.x.
>
> Regarding performance, a change always has positive and negative
> consequences. It is important to understand them both, informed by real
> world use cases. My guess is you have real world use cases, Reid. Your
> results will be meaningful.
>
> Synthetic benchmarks are less interesting unless the regression is obvious
> and more like a bug than a consequence. Sure they will report positive and
> negative changes, but does that actually mean anything? It depends.
> Sometimes it will only mean something if we care about supporting the
> synthetic benchmark as a first class use case. (Usually we don’t; but
> universal cross system bench tools like YCSB are exceptions.)
>
>
> > On May 31, 2021, at 9:25 AM, Reid Chan <re...@gmail.com> wrote:
> >
> > Thanks to Andrew and Sean's help, I managed to release the first
> candidate
> > of 1.7.0 (at least it is a beginning, and graduated from green hand).
> > BTW, The [VOTE]
> > <
> https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E
> >
> >
> > The following are my thoughts:
> > I'm willing to continue branch-1's life as a RM.
> > And before EOL branch-1, I need to announce EOL of branch-1.4.
> > While maintaining the branch-1, I also will do some benchmarks between
> 1.7+
> > and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing to
> > spend some time diving in.
> > After the performance issue is done, I need to review the upgrade from
> 1.x
> > to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal some
> > problems already.
> > I will announce EOL of branch-1 if listed above are done.
> >
> > Probably more than 1 year, by estimation, if I have to do it all alone.
> The
> > most time-spending should be performance diving in (if there was) and
> > upgrade review.
> >
> > Any thought is appreciated.
> >
> >
> > ---
> > Best regards,
> > R.C
> >
> >
> >
> >
> >> On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com>
> wrote:
> >>
> >>
> >> FYI, a JDK issue when I was making the 1.7.0 release.
> >>
> >>
> >>
> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
> >>
> >>
> >> ---
> >> Best Regards,
> >> R.C
> >>
> >>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
> wrote:
> >>>
> >>> Is it time to consider EOL of branch-1 and all 1.x releases ?
> >>>
> >>> There doesn't seem to be much developer interest in branch-1 beyond
> >>> occasional maintenance. This is understandable. Per our compatibility
> >>> guidelines, branch-1 commits must be compatible with Java 7, and the
> range
> >>> of acceptable versions of third party dependencies is also restricted
> due
> >>> to Java 7 compatibility requirements. Most developers are writing code
> >>> with
> >>> Java 8+ idioms these days. For that reason and because the branch-1
> code
> >>> base is generally aged at this point, all but trivial (or lucky!)
> >>> backports
> >>> require substantial changes in order to integrate adequately. Let me
> also
> >>> observe that branch-1 artifacts are not fully compatible with Java 11
> or
> >>> later. (The shell is a good example of such issues: The version of
> >>> jruby-complete required by branch-1 is not compatible with Java 11 and
> >>> upgrading to the version used by branch-2 causes shell commands to
> error
> >>> out due to Ruby language changes.)
> >>>
> >>> We can a priori determine there is insufficient motivation for
> production
> >>> of release artifacts for the PMC to vote upon. Otherwise, someone would
> >>> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> >>> releases from branch-2 derived code in 2020, and so far we have had 3
> >>> releases from branch-2 derived code in 2021. In contrast, we had 8
> >>> releases
> >>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> and
> >>> so far 0 releases from branch-1 in 2021.
> >>>
> >>> *  2021202020191.x0282.x31312*
> >>>
> >>> If there is someone interested in continuing branch-1, now is the time
> to
> >>> commit. However let me be clear that simply expressing an abstract
> desire
> >>> to see continued branch-1 releases will not be that useful. It will be
> >>> noted, but will not have much real world impact. Apache is a
> do-ocracy. In
> >>> the absence of intrinsic motivation of project participants, which is
> what
> >>> we seem to have here, you will need to do something: Fix the
> compatibility
> >>> issues, if any between the last release of 1.x and the current branch-1
> >>> head; fix any failing and flaky unit tests; produce release artifacts;
> and
> >>> submit those artifacts to the PMC for voting. Or, convince someone with
> >>> commit rights and/or PMC membership to undertake these actions on your
> >>> behalf.
> >>>
> >>> Otherwise, I respectfully submit for your consideration, it is time to
> >>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
> >>> has
> >>> effectively already happened.
> >>>
> >>> --
> >>> Best regards,
> >>> Andrew
> >>>
> >>> Words like orphans lost among the crosstalk, meaning torn from truth's
> >>> decrepit hands
> >>>   - A23, Crosstalk
> >>>
> >>
>

Re: EOL branch-1 and all 1.x ?

[Andrew Purtell <an...@gmail.com>]

It would be good to do the performance work at least, if you are up for it. There are always going to be consequences for the kind of significant evolution that 2.x represents over 1.x. 

Regarding performance, a change always has positive and negative consequences. It is important to understand them both, informed by real world use cases. My guess is you have real world use cases, Reid. Your results will be meaningful. 

Synthetic benchmarks are less interesting unless the regression is obvious and more like a bug than a consequence. Sure they will report positive and negative changes, but does that actually mean anything? It depends. Sometimes it will only mean something if we care about supporting the synthetic benchmark as a first class use case. (Usually we don’t; but universal cross system bench tools like YCSB are exceptions.)


> On May 31, 2021, at 9:25 AM, Reid Chan <re...@gmail.com> wrote:
> 
> Thanks to Andrew and Sean's help, I managed to release the first candidate
> of 1.7.0 (at least it is a beginning, and graduated from green hand).
> BTW, The [VOTE]
> <https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E>
> 
> The following are my thoughts:
> I'm willing to continue branch-1's life as a RM.
> And before EOL branch-1, I need to announce EOL of branch-1.4.
> While maintaining the branch-1, I also will do some benchmarks between 1.7+
> and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing to
> spend some time diving in.
> After the performance issue is done, I need to review the upgrade from 1.x
> to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal some
> problems already.
> I will announce EOL of branch-1 if listed above are done.
> 
> Probably more than 1 year, by estimation, if I have to do it all alone. The
> most time-spending should be performance diving in (if there was) and
> upgrade review.
> 
> Any thought is appreciated.
> 
> 
> ---
> Best regards,
> R.C
> 
> 
> 
> 
>> On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com> wrote:
>> 
>> 
>> FYI, a JDK issue when I was making the 1.7.0 release.
>> 
>> 
>> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
>> 
>> 
>> ---
>> Best Regards,
>> R.C
>> 
>>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:
>>> 
>>> Is it time to consider EOL of branch-1 and all 1.x releases ?
>>> 
>>> There doesn't seem to be much developer interest in branch-1 beyond
>>> occasional maintenance. This is understandable. Per our compatibility
>>> guidelines, branch-1 commits must be compatible with Java 7, and the range
>>> of acceptable versions of third party dependencies is also restricted due
>>> to Java 7 compatibility requirements. Most developers are writing code
>>> with
>>> Java 8+ idioms these days. For that reason and because the branch-1 code
>>> base is generally aged at this point, all but trivial (or lucky!)
>>> backports
>>> require substantial changes in order to integrate adequately. Let me also
>>> observe that branch-1 artifacts are not fully compatible with Java 11 or
>>> later. (The shell is a good example of such issues: The version of
>>> jruby-complete required by branch-1 is not compatible with Java 11 and
>>> upgrading to the version used by branch-2 causes shell commands to error
>>> out due to Ruby language changes.)
>>> 
>>> We can a priori determine there is insufficient motivation for production
>>> of release artifacts for the PMC to vote upon. Otherwise, someone would
>>> have done it. We had 12 releases from branch-2 derived code in 2019, 13
>>> releases from branch-2 derived code in 2020, and so far we have had 3
>>> releases from branch-2 derived code in 2021. In contrast, we had 8
>>> releases
>>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
>>> so far 0 releases from branch-1 in 2021.
>>> 
>>> *  2021202020191.x0282.x31312*
>>> 
>>> If there is someone interested in continuing branch-1, now is the time to
>>> commit. However let me be clear that simply expressing an abstract desire
>>> to see continued branch-1 releases will not be that useful. It will be
>>> noted, but will not have much real world impact. Apache is a do-ocracy. In
>>> the absence of intrinsic motivation of project participants, which is what
>>> we seem to have here, you will need to do something: Fix the compatibility
>>> issues, if any between the last release of 1.x and the current branch-1
>>> head; fix any failing and flaky unit tests; produce release artifacts; and
>>> submit those artifacts to the PMC for voting. Or, convince someone with
>>> commit rights and/or PMC membership to undertake these actions on your
>>> behalf.
>>> 
>>> Otherwise, I respectfully submit for your consideration, it is time to
>>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
>>> has
>>> effectively already happened.
>>> 
>>> --
>>> Best regards,
>>> Andrew
>>> 
>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>> decrepit hands
>>>   - A23, Crosstalk
>>> 
>> 

Re: EOL branch-1 and all 1.x ?

[Andrew Purtell <an...@gmail.com>]

It would be good to do the performance work at least, if you are up for it. There are always going to be consequences for the kind of significant evolution that 2.x represents over 1.x. 

Regarding performance, a change always has positive and negative consequences. It is important to understand them both, informed by real world use cases. My guess is you have real world use cases, Reid. Your results will be meaningful. 

Synthetic benchmarks are less interesting unless the regression is obvious and more like a bug than a consequence. Sure they will report positive and negative changes, but does that actually mean anything? It depends. Sometimes it will only mean something if we care about supporting the synthetic benchmark as a first class use case. (Usually we don’t; but universal cross system bench tools like YCSB are exceptions.)


> On May 31, 2021, at 9:25 AM, Reid Chan <re...@gmail.com> wrote:
> 
> Thanks to Andrew and Sean's help, I managed to release the first candidate
> of 1.7.0 (at least it is a beginning, and graduated from green hand).
> BTW, The [VOTE]
> <https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E>
> 
> The following are my thoughts:
> I'm willing to continue branch-1's life as a RM.
> And before EOL branch-1, I need to announce EOL of branch-1.4.
> While maintaining the branch-1, I also will do some benchmarks between 1.7+
> and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing to
> spend some time diving in.
> After the performance issue is done, I need to review the upgrade from 1.x
> to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal some
> problems already.
> I will announce EOL of branch-1 if listed above are done.
> 
> Probably more than 1 year, by estimation, if I have to do it all alone. The
> most time-spending should be performance diving in (if there was) and
> upgrade review.
> 
> Any thought is appreciated.
> 
> 
> ---
> Best regards,
> R.C
> 
> 
> 
> 
>> On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com> wrote:
>> 
>> 
>> FYI, a JDK issue when I was making the 1.7.0 release.
>> 
>> 
>> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
>> 
>> 
>> ---
>> Best Regards,
>> R.C
>> 
>>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:
>>> 
>>> Is it time to consider EOL of branch-1 and all 1.x releases ?
>>> 
>>> There doesn't seem to be much developer interest in branch-1 beyond
>>> occasional maintenance. This is understandable. Per our compatibility
>>> guidelines, branch-1 commits must be compatible with Java 7, and the range
>>> of acceptable versions of third party dependencies is also restricted due
>>> to Java 7 compatibility requirements. Most developers are writing code
>>> with
>>> Java 8+ idioms these days. For that reason and because the branch-1 code
>>> base is generally aged at this point, all but trivial (or lucky!)
>>> backports
>>> require substantial changes in order to integrate adequately. Let me also
>>> observe that branch-1 artifacts are not fully compatible with Java 11 or
>>> later. (The shell is a good example of such issues: The version of
>>> jruby-complete required by branch-1 is not compatible with Java 11 and
>>> upgrading to the version used by branch-2 causes shell commands to error
>>> out due to Ruby language changes.)
>>> 
>>> We can a priori determine there is insufficient motivation for production
>>> of release artifacts for the PMC to vote upon. Otherwise, someone would
>>> have done it. We had 12 releases from branch-2 derived code in 2019, 13
>>> releases from branch-2 derived code in 2020, and so far we have had 3
>>> releases from branch-2 derived code in 2021. In contrast, we had 8
>>> releases
>>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
>>> so far 0 releases from branch-1 in 2021.
>>> 
>>> *  2021202020191.x0282.x31312*
>>> 
>>> If there is someone interested in continuing branch-1, now is the time to
>>> commit. However let me be clear that simply expressing an abstract desire
>>> to see continued branch-1 releases will not be that useful. It will be
>>> noted, but will not have much real world impact. Apache is a do-ocracy. In
>>> the absence of intrinsic motivation of project participants, which is what
>>> we seem to have here, you will need to do something: Fix the compatibility
>>> issues, if any between the last release of 1.x and the current branch-1
>>> head; fix any failing and flaky unit tests; produce release artifacts; and
>>> submit those artifacts to the PMC for voting. Or, convince someone with
>>> commit rights and/or PMC membership to undertake these actions on your
>>> behalf.
>>> 
>>> Otherwise, I respectfully submit for your consideration, it is time to
>>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
>>> has
>>> effectively already happened.
>>> 
>>> --
>>> Best regards,
>>> Andrew
>>> 
>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>> decrepit hands
>>>   - A23, Crosstalk
>>> 
>> 

Re: EOL branch-1 and all 1.x ?

[Reid Chan <re...@gmail.com>]

Thanks to Andrew and Sean's help, I managed to release the first candidate
of 1.7.0 (at least it is a beginning, and graduated from green hand).
BTW, The [VOTE]
<https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E>

The following are my thoughts:
I'm willing to continue branch-1's life as a RM.
And before EOL branch-1, I need to announce EOL of branch-1.4.
While maintaining the branch-1, I also will do some benchmarks between 1.7+
and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing to
spend some time diving in.
After the performance issue is done, I need to review the upgrade from 1.x
to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal some
problems already.
I will announce EOL of branch-1 if listed above are done.

Probably more than 1 year, by estimation, if I have to do it all alone. The
most time-spending should be performance diving in (if there was) and
upgrade review.

Any thought is appreciated.


---
Best regards,
R.C




On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com> wrote:

>
> FYI, a JDK issue when I was making the 1.7.0 release.
>
>
> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
>
>
> ---
> Best Regards,
> R.C
>
> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:
>
>> Is it time to consider EOL of branch-1 and all 1.x releases ?
>>
>> There doesn't seem to be much developer interest in branch-1 beyond
>> occasional maintenance. This is understandable. Per our compatibility
>> guidelines, branch-1 commits must be compatible with Java 7, and the range
>> of acceptable versions of third party dependencies is also restricted due
>> to Java 7 compatibility requirements. Most developers are writing code
>> with
>> Java 8+ idioms these days. For that reason and because the branch-1 code
>> base is generally aged at this point, all but trivial (or lucky!)
>> backports
>> require substantial changes in order to integrate adequately. Let me also
>> observe that branch-1 artifacts are not fully compatible with Java 11 or
>> later. (The shell is a good example of such issues: The version of
>> jruby-complete required by branch-1 is not compatible with Java 11 and
>> upgrading to the version used by branch-2 causes shell commands to error
>> out due to Ruby language changes.)
>>
>> We can a priori determine there is insufficient motivation for production
>> of release artifacts for the PMC to vote upon. Otherwise, someone would
>> have done it. We had 12 releases from branch-2 derived code in 2019, 13
>> releases from branch-2 derived code in 2020, and so far we have had 3
>> releases from branch-2 derived code in 2021. In contrast, we had 8
>> releases
>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
>> so far 0 releases from branch-1 in 2021.
>>
>> *  2021202020191.x0282.x31312*
>>
>> If there is someone interested in continuing branch-1, now is the time to
>> commit. However let me be clear that simply expressing an abstract desire
>> to see continued branch-1 releases will not be that useful. It will be
>> noted, but will not have much real world impact. Apache is a do-ocracy. In
>> the absence of intrinsic motivation of project participants, which is what
>> we seem to have here, you will need to do something: Fix the compatibility
>> issues, if any between the last release of 1.x and the current branch-1
>> head; fix any failing and flaky unit tests; produce release artifacts; and
>> submit those artifacts to the PMC for voting. Or, convince someone with
>> commit rights and/or PMC membership to undertake these actions on your
>> behalf.
>>
>> Otherwise, I respectfully submit for your consideration, it is time to
>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
>> has
>> effectively already happened.
>>
>> --
>> Best regards,
>> Andrew
>>
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>    - A23, Crosstalk
>>
>

Re: EOL branch-1 and all 1.x ?

[Reid Chan <re...@gmail.com>]

Thanks to Andrew and Sean's help, I managed to release the first candidate
of 1.7.0 (at least it is a beginning, and graduated from green hand).
BTW, The [VOTE]
<https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E>

The following are my thoughts:
I'm willing to continue branch-1's life as a RM.
And before EOL branch-1, I need to announce EOL of branch-1.4.
While maintaining the branch-1, I also will do some benchmarks between 1.7+
and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing to
spend some time diving in.
After the performance issue is done, I need to review the upgrade from 1.x
to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal some
problems already.
I will announce EOL of branch-1 if listed above are done.

Probably more than 1 year, by estimation, if I have to do it all alone. The
most time-spending should be performance diving in (if there was) and
upgrade review.

Any thought is appreciated.


---
Best regards,
R.C




On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <re...@gmail.com> wrote:

>
> FYI, a JDK issue when I was making the 1.7.0 release.
>
>
> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E
>
>
> ---
> Best Regards,
> R.C
>
> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:
>
>> Is it time to consider EOL of branch-1 and all 1.x releases ?
>>
>> There doesn't seem to be much developer interest in branch-1 beyond
>> occasional maintenance. This is understandable. Per our compatibility
>> guidelines, branch-1 commits must be compatible with Java 7, and the range
>> of acceptable versions of third party dependencies is also restricted due
>> to Java 7 compatibility requirements. Most developers are writing code
>> with
>> Java 8+ idioms these days. For that reason and because the branch-1 code
>> base is generally aged at this point, all but trivial (or lucky!)
>> backports
>> require substantial changes in order to integrate adequately. Let me also
>> observe that branch-1 artifacts are not fully compatible with Java 11 or
>> later. (The shell is a good example of such issues: The version of
>> jruby-complete required by branch-1 is not compatible with Java 11 and
>> upgrading to the version used by branch-2 causes shell commands to error
>> out due to Ruby language changes.)
>>
>> We can a priori determine there is insufficient motivation for production
>> of release artifacts for the PMC to vote upon. Otherwise, someone would
>> have done it. We had 12 releases from branch-2 derived code in 2019, 13
>> releases from branch-2 derived code in 2020, and so far we have had 3
>> releases from branch-2 derived code in 2021. In contrast, we had 8
>> releases
>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
>> so far 0 releases from branch-1 in 2021.
>>
>> *  2021202020191.x0282.x31312*
>>
>> If there is someone interested in continuing branch-1, now is the time to
>> commit. However let me be clear that simply expressing an abstract desire
>> to see continued branch-1 releases will not be that useful. It will be
>> noted, but will not have much real world impact. Apache is a do-ocracy. In
>> the absence of intrinsic motivation of project participants, which is what
>> we seem to have here, you will need to do something: Fix the compatibility
>> issues, if any between the last release of 1.x and the current branch-1
>> head; fix any failing and flaky unit tests; produce release artifacts; and
>> submit those artifacts to the PMC for voting. Or, convince someone with
>> commit rights and/or PMC membership to undertake these actions on your
>> behalf.
>>
>> Otherwise, I respectfully submit for your consideration, it is time to
>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
>> has
>> effectively already happened.
>>
>> --
>> Best regards,
>> Andrew
>>
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>    - A23, Crosstalk
>>
>

Re: EOL branch-1 and all 1.x ?

[Reid Chan <re...@gmail.com>]

FYI, a JDK issue when I was making the 1.7.0 release.

https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E


---
Best Regards,
R.C

On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:

> Is it time to consider EOL of branch-1 and all 1.x releases ?
>
> There doesn't seem to be much developer interest in branch-1 beyond
> occasional maintenance. This is understandable. Per our compatibility
> guidelines, branch-1 commits must be compatible with Java 7, and the range
> of acceptable versions of third party dependencies is also restricted due
> to Java 7 compatibility requirements. Most developers are writing code with
> Java 8+ idioms these days. For that reason and because the branch-1 code
> base is generally aged at this point, all but trivial (or lucky!) backports
> require substantial changes in order to integrate adequately. Let me also
> observe that branch-1 artifacts are not fully compatible with Java 11 or
> later. (The shell is a good example of such issues: The version of
> jruby-complete required by branch-1 is not compatible with Java 11 and
> upgrading to the version used by branch-2 causes shell commands to error
> out due to Ruby language changes.)
>
> We can a priori determine there is insufficient motivation for production
> of release artifacts for the PMC to vote upon. Otherwise, someone would
> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> releases from branch-2 derived code in 2020, and so far we have had 3
> releases from branch-2 derived code in 2021. In contrast, we had 8 releases
> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
> so far 0 releases from branch-1 in 2021.
>
> *  2021202020191.x0282.x31312*
>
> If there is someone interested in continuing branch-1, now is the time to
> commit. However let me be clear that simply expressing an abstract desire
> to see continued branch-1 releases will not be that useful. It will be
> noted, but will not have much real world impact. Apache is a do-ocracy. In
> the absence of intrinsic motivation of project participants, which is what
> we seem to have here, you will need to do something: Fix the compatibility
> issues, if any between the last release of 1.x and the current branch-1
> head; fix any failing and flaky unit tests; produce release artifacts; and
> submit those artifacts to the PMC for voting. Or, convince someone with
> commit rights and/or PMC membership to undertake these actions on your
> behalf.
>
> Otherwise, I respectfully submit for your consideration, it is time to
> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
> effectively already happened.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: EOL branch-1 and all 1.x ?

["张铎 (Duo Zhang)" <pa...@gmail.com>]

+1 on EOL branch-1 and all 1.x.

Thanks Andrew for the write up.

Bharath Vissapragada <bh...@apache.org>于2021年4月1日 周四08:07写道：

> Agreed. +1 for EOL'ing.
>
> On Wed, Mar 31, 2021 at 3:08 PM Stack <st...@duboce.net> wrote:
>
> > Thanks for the write-up Andrew. +1 on its EOL'ing.
> > S
> >
> > On Wed, Mar 31, 2021 at 3:03 PM Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > Is it time to consider EOL of branch-1 and all 1.x releases ?
> > >
> > > There doesn't seem to be much developer interest in branch-1 beyond
> > > occasional maintenance. This is understandable. Per our compatibility
> > > guidelines, branch-1 commits must be compatible with Java 7, and the
> > range
> > > of acceptable versions of third party dependencies is also restricted
> due
> > > to Java 7 compatibility requirements. Most developers are writing code
> > with
> > > Java 8+ idioms these days. For that reason and because the branch-1
> code
> > > base is generally aged at this point, all but trivial (or lucky!)
> > backports
> > > require substantial changes in order to integrate adequately. Let me
> also
> > > observe that branch-1 artifacts are not fully compatible with Java 11
> or
> > > later. (The shell is a good example of such issues: The version of
> > > jruby-complete required by branch-1 is not compatible with Java 11 and
> > > upgrading to the version used by branch-2 causes shell commands to
> error
> > > out due to Ruby language changes.)
> > >
> > > We can a priori determine there is insufficient motivation for
> production
> > > of release artifacts for the PMC to vote upon. Otherwise, someone would
> > > have done it. We had 12 releases from branch-2 derived code in 2019, 13
> > > releases from branch-2 derived code in 2020, and so far we have had 3
> > > releases from branch-2 derived code in 2021. In contrast, we had 8
> > releases
> > > from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> and
> > > so far 0 releases from branch-1 in 2021.
> > >
> > > *  2021202020191.x0282.x31312*
> > >
> > > If there is someone interested in continuing branch-1, now is the time
> to
> > > commit. However let me be clear that simply expressing an abstract
> desire
> > > to see continued branch-1 releases will not be that useful. It will be
> > > noted, but will not have much real world impact. Apache is a do-ocracy.
> > In
> > > the absence of intrinsic motivation of project participants, which is
> > what
> > > we seem to have here, you will need to do something: Fix the
> > compatibility
> > > issues, if any between the last release of 1.x and the current branch-1
> > > head; fix any failing and flaky unit tests; produce release artifacts;
> > and
> > > submit those artifacts to the PMC for voting. Or, convince someone with
> > > commit rights and/or PMC membership to undertake these actions on your
> > > behalf.
> > >
> > > Otherwise, I respectfully submit for your consideration, it is time to
> > > declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
> > has
> > > effectively already happened.
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> > >
> >
>

Re: EOL branch-1 and all 1.x ?

[Bharath Vissapragada <bh...@apache.org>]

Agreed. +1 for EOL'ing.

On Wed, Mar 31, 2021 at 3:08 PM Stack <st...@duboce.net> wrote:

> Thanks for the write-up Andrew. +1 on its EOL'ing.
> S
>
> On Wed, Mar 31, 2021 at 3:03 PM Andrew Purtell <ap...@apache.org>
> wrote:
>
> > Is it time to consider EOL of branch-1 and all 1.x releases ?
> >
> > There doesn't seem to be much developer interest in branch-1 beyond
> > occasional maintenance. This is understandable. Per our compatibility
> > guidelines, branch-1 commits must be compatible with Java 7, and the
> range
> > of acceptable versions of third party dependencies is also restricted due
> > to Java 7 compatibility requirements. Most developers are writing code
> with
> > Java 8+ idioms these days. For that reason and because the branch-1 code
> > base is generally aged at this point, all but trivial (or lucky!)
> backports
> > require substantial changes in order to integrate adequately. Let me also
> > observe that branch-1 artifacts are not fully compatible with Java 11 or
> > later. (The shell is a good example of such issues: The version of
> > jruby-complete required by branch-1 is not compatible with Java 11 and
> > upgrading to the version used by branch-2 causes shell commands to error
> > out due to Ruby language changes.)
> >
> > We can a priori determine there is insufficient motivation for production
> > of release artifacts for the PMC to vote upon. Otherwise, someone would
> > have done it. We had 12 releases from branch-2 derived code in 2019, 13
> > releases from branch-2 derived code in 2020, and so far we have had 3
> > releases from branch-2 derived code in 2021. In contrast, we had 8
> releases
> > from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
> > so far 0 releases from branch-1 in 2021.
> >
> > *  2021202020191.x0282.x31312*
> >
> > If there is someone interested in continuing branch-1, now is the time to
> > commit. However let me be clear that simply expressing an abstract desire
> > to see continued branch-1 releases will not be that useful. It will be
> > noted, but will not have much real world impact. Apache is a do-ocracy.
> In
> > the absence of intrinsic motivation of project participants, which is
> what
> > we seem to have here, you will need to do something: Fix the
> compatibility
> > issues, if any between the last release of 1.x and the current branch-1
> > head; fix any failing and flaky unit tests; produce release artifacts;
> and
> > submit those artifacts to the PMC for voting. Or, convince someone with
> > commit rights and/or PMC membership to undertake these actions on your
> > behalf.
> >
> > Otherwise, I respectfully submit for your consideration, it is time to
> > declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
> has
> > effectively already happened.
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>

Re: EOL branch-1 and all 1.x ?

[Stack <st...@duboce.net>]

Thanks for the write-up Andrew. +1 on its EOL'ing.
S

On Wed, Mar 31, 2021 at 3:03 PM Andrew Purtell <ap...@apache.org> wrote:

> Is it time to consider EOL of branch-1 and all 1.x releases ?
>
> There doesn't seem to be much developer interest in branch-1 beyond
> occasional maintenance. This is understandable. Per our compatibility
> guidelines, branch-1 commits must be compatible with Java 7, and the range
> of acceptable versions of third party dependencies is also restricted due
> to Java 7 compatibility requirements. Most developers are writing code with
> Java 8+ idioms these days. For that reason and because the branch-1 code
> base is generally aged at this point, all but trivial (or lucky!) backports
> require substantial changes in order to integrate adequately. Let me also
> observe that branch-1 artifacts are not fully compatible with Java 11 or
> later. (The shell is a good example of such issues: The version of
> jruby-complete required by branch-1 is not compatible with Java 11 and
> upgrading to the version used by branch-2 causes shell commands to error
> out due to Ruby language changes.)
>
> We can a priori determine there is insufficient motivation for production
> of release artifacts for the PMC to vote upon. Otherwise, someone would
> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> releases from branch-2 derived code in 2020, and so far we have had 3
> releases from branch-2 derived code in 2021. In contrast, we had 8 releases
> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
> so far 0 releases from branch-1 in 2021.
>
> *  2021202020191.x0282.x31312*
>
> If there is someone interested in continuing branch-1, now is the time to
> commit. However let me be clear that simply expressing an abstract desire
> to see continued branch-1 releases will not be that useful. It will be
> noted, but will not have much real world impact. Apache is a do-ocracy. In
> the absence of intrinsic motivation of project participants, which is what
> we seem to have here, you will need to do something: Fix the compatibility
> issues, if any between the last release of 1.x and the current branch-1
> head; fix any failing and flaky unit tests; produce release artifacts; and
> submit those artifacts to the PMC for voting. Or, convince someone with
> commit rights and/or PMC membership to undertake these actions on your
> behalf.
>
> Otherwise, I respectfully submit for your consideration, it is time to
> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
> effectively already happened.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: EOL branch-1 and all 1.x ?

[Huaxiang Sun <hu...@gmail.com>]

> do you have a JIRA covering this change? What is your suggested
> remediation for branch-2 releases? Can/should we make the fix the default
> behavior, or is there good reason to keep us running in this “slow mode”
by
> default, require operators to opt-in to the perf boost?

The change of Rpc PriorityQueue scheduler
from FastPathBalancedQueueRpcExecutor to RWQueueRpcExecutor causes
meta scan throughput regression. This change is introduced by HBASE-22280,
I am about to follow up in HBASE-22280.
Could be a real production issue addressed by this change, not sure at this
moment.


On Thu, Apr 1, 2021 at 11:11 AM Nick Dimiduk <nd...@apache.org> wrote:

> Also big +1 from me.
>
> On Thu, Apr 1, 2021 at 09:08 Huaxiang Sun <hu...@gmail.com> wrote:
>
> > Per performance regression concern, we had one such issue for meta when
> > upgrading from 1.2 to 2.3.
> > It turned out to be default rpc scheduling changed from branch-1 to
> > branch-2, and it causes performance regression.
>
>
> Huaxiang, do you have a JIRA covering this change? What is your suggested
> remediation for branch-2 releases? Can/should we make the fix the default
> behavior, or is there good reason to keep us running in this “slow mode” by
> default, require operators to opt-in to the perf boost?
>
> Thanks,
> Nick
>
> On Thu, Apr 1, 2021 at 8:22 AM Pankaj Kumar <pa...@gmail.com>
> > wrote:
> >
> > > +1 on EOL branch-1 and all branch-1.x.
> > >
> > > Regards,
> > > Pankaj
> > >
> > > On Thu, Apr 1, 2021 at 3:34 AM Andrew Purtell <ap...@apache.org>
> > wrote:
> > >
> > > > Is it time to consider EOL of branch-1 and all 1.x releases ?
> > > >
> > > > There doesn't seem to be much developer interest in branch-1 beyond
> > > > occasional maintenance. This is understandable. Per our compatibility
> > > > guidelines, branch-1 commits must be compatible with Java 7, and the
> > > range
> > > > of acceptable versions of third party dependencies is also restricted
> > due
> > > > to Java 7 compatibility requirements. Most developers are writing
> code
> > > with
> > > > Java 8+ idioms these days. For that reason and because the branch-1
> > code
> > > > base is generally aged at this point, all but trivial (or lucky!)
> > > backports
> > > > require substantial changes in order to integrate adequately. Let me
> > also
> > > > observe that branch-1 artifacts are not fully compatible with Java 11
> > or
> > > > later. (The shell is a good example of such issues: The version of
> > > > jruby-complete required by branch-1 is not compatible with Java 11
> and
> > > > upgrading to the version used by branch-2 causes shell commands to
> > error
> > > > out due to Ruby language changes.)
> > > >
> > > > We can a priori determine there is insufficient motivation for
> > production
> > > > of release artifacts for the PMC to vote upon. Otherwise, someone
> would
> > > > have done it. We had 12 releases from branch-2 derived code in 2019,
> 13
> > > > releases from branch-2 derived code in 2020, and so far we have had 3
> > > > releases from branch-2 derived code in 2021. In contrast, we had 8
> > > releases
> > > > from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> > and
> > > > so far 0 releases from branch-1 in 2021.
> > > >
> > > > *  2021202020191.x0282.x31312*
> > > >
> > > > If there is someone interested in continuing branch-1, now is the
> time
> > to
> > > > commit. However let me be clear that simply expressing an abstract
> > desire
> > > > to see continued branch-1 releases will not be that useful. It will
> be
> > > > noted, but will not have much real world impact. Apache is a
> do-ocracy.
> > > In
> > > > the absence of intrinsic motivation of project participants, which is
> > > what
> > > > we seem to have here, you will need to do something: Fix the
> > > compatibility
> > > > issues, if any between the last release of 1.x and the current
> branch-1
> > > > head; fix any failing and flaky unit tests; produce release
> artifacts;
> > > and
> > > > submit those artifacts to the PMC for voting. Or, convince someone
> with
> > > > commit rights and/or PMC membership to undertake these actions on
> your
> > > > behalf.
> > > >
> > > > Otherwise, I respectfully submit for your consideration, it is time
> to
> > > > declare  branch-1 and all 1.x code lines EOL, simply acknowledging
> what
> > > has
> > > > effectively already happened.
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >    - A23, Crosstalk
> > > >
> > >
> >
>

Re: EOL branch-1 and all 1.x ?

[Geoffrey Jacoby <gj...@apache.org>]

Thanks, Reid, for volunteering to RM 1.7.0.  If you would like some
assistance in stabilizing the tests and getting branch-1 into a
release-ready state, please let me know. I see the flaky list is pretty
long and I'm happy to take some JIRAs.

Geoffrey

On Thu, Apr 1, 2021 at 11:22 AM Andrew Purtell <ap...@apache.org> wrote:

> Reid Chan has committed to completing the 1.7.0 release, please see
> https://issues.apache.org/jira/browse/HBASE-25725 .
>
> So the execution of a public EOL statement for branch-1 can proceed, by the
> apparent consensus surfaced by this thread, but we should respect his wish
> to complete 1.7.0. This makes a nice end to branch-1, IMHO, flushing out
> all of the unreleased changes in that branch.
>
> On Thu, Apr 1, 2021 at 11:11 AM Nick Dimiduk <nd...@apache.org> wrote:
>
> > Also big +1 from me.
> >
> > On Thu, Apr 1, 2021 at 09:08 Huaxiang Sun <hu...@gmail.com> wrote:
> >
> > > Per performance regression concern, we had one such issue for meta when
> > > upgrading from 1.2 to 2.3.
> > > It turned out to be default rpc scheduling changed from branch-1 to
> > > branch-2, and it causes performance regression.
> >
> >
> > Huaxiang, do you have a JIRA covering this change? What is your suggested
> > remediation for branch-2 releases? Can/should we make the fix the default
> > behavior, or is there good reason to keep us running in this “slow mode”
> by
> > default, require operators to opt-in to the perf boost?
> >
> > Thanks,
> > Nick
> >
> > On Thu, Apr 1, 2021 at 8:22 AM Pankaj Kumar <pa...@gmail.com>
> > > wrote:
> > >
> > > > +1 on EOL branch-1 and all branch-1.x.
> > > >
> > > > Regards,
> > > > Pankaj
> > > >
> > > > On Thu, Apr 1, 2021 at 3:34 AM Andrew Purtell <ap...@apache.org>
> > > wrote:
> > > >
> > > > > Is it time to consider EOL of branch-1 and all 1.x releases ?
> > > > >
> > > > > There doesn't seem to be much developer interest in branch-1 beyond
> > > > > occasional maintenance. This is understandable. Per our
> compatibility
> > > > > guidelines, branch-1 commits must be compatible with Java 7, and
> the
> > > > range
> > > > > of acceptable versions of third party dependencies is also
> restricted
> > > due
> > > > > to Java 7 compatibility requirements. Most developers are writing
> > code
> > > > with
> > > > > Java 8+ idioms these days. For that reason and because the branch-1
> > > code
> > > > > base is generally aged at this point, all but trivial (or lucky!)
> > > > backports
> > > > > require substantial changes in order to integrate adequately. Let
> me
> > > also
> > > > > observe that branch-1 artifacts are not fully compatible with Java
> 11
> > > or
> > > > > later. (The shell is a good example of such issues: The version of
> > > > > jruby-complete required by branch-1 is not compatible with Java 11
> > and
> > > > > upgrading to the version used by branch-2 causes shell commands to
> > > error
> > > > > out due to Ruby language changes.)
> > > > >
> > > > > We can a priori determine there is insufficient motivation for
> > > production
> > > > > of release artifacts for the PMC to vote upon. Otherwise, someone
> > would
> > > > > have done it. We had 12 releases from branch-2 derived code in
> 2019,
> > 13
> > > > > releases from branch-2 derived code in 2020, and so far we have
> had 3
> > > > > releases from branch-2 derived code in 2021. In contrast, we had 8
> > > > releases
> > > > > from branch-1 derived code in 2019, 0 releases from branch-1 in
> 2020,
> > > and
> > > > > so far 0 releases from branch-1 in 2021.
> > > > >
> > > > > *  2021202020191.x0282.x31312*
> > > > >
> > > > > If there is someone interested in continuing branch-1, now is the
> > time
> > > to
> > > > > commit. However let me be clear that simply expressing an abstract
> > > desire
> > > > > to see continued branch-1 releases will not be that useful. It will
> > be
> > > > > noted, but will not have much real world impact. Apache is a
> > do-ocracy.
> > > > In
> > > > > the absence of intrinsic motivation of project participants, which
> is
> > > > what
> > > > > we seem to have here, you will need to do something: Fix the
> > > > compatibility
> > > > > issues, if any between the last release of 1.x and the current
> > branch-1
> > > > > head; fix any failing and flaky unit tests; produce release
> > artifacts;
> > > > and
> > > > > submit those artifacts to the PMC for voting. Or, convince someone
> > with
> > > > > commit rights and/or PMC membership to undertake these actions on
> > your
> > > > > behalf.
> > > > >
> > > > > Otherwise, I respectfully submit for your consideration, it is time
> > to
> > > > > declare  branch-1 and all 1.x code lines EOL, simply acknowledging
> > what
> > > > has
> > > > > effectively already happened.
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > > > Words like orphans lost among the crosstalk, meaning torn from
> > truth's
> > > > > decrepit hands
> > > > >    - A23, Crosstalk
> > > > >
> > > >
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: EOL branch-1 and all 1.x ?

[Andrew Purtell <ap...@apache.org>]

Reid Chan has committed to completing the 1.7.0 release, please see
https://issues.apache.org/jira/browse/HBASE-25725 .

So the execution of a public EOL statement for branch-1 can proceed, by the
apparent consensus surfaced by this thread, but we should respect his wish
to complete 1.7.0. This makes a nice end to branch-1, IMHO, flushing out
all of the unreleased changes in that branch.

On Thu, Apr 1, 2021 at 11:11 AM Nick Dimiduk <nd...@apache.org> wrote:

> Also big +1 from me.
>
> On Thu, Apr 1, 2021 at 09:08 Huaxiang Sun <hu...@gmail.com> wrote:
>
> > Per performance regression concern, we had one such issue for meta when
> > upgrading from 1.2 to 2.3.
> > It turned out to be default rpc scheduling changed from branch-1 to
> > branch-2, and it causes performance regression.
>
>
> Huaxiang, do you have a JIRA covering this change? What is your suggested
> remediation for branch-2 releases? Can/should we make the fix the default
> behavior, or is there good reason to keep us running in this “slow mode” by
> default, require operators to opt-in to the perf boost?
>
> Thanks,
> Nick
>
> On Thu, Apr 1, 2021 at 8:22 AM Pankaj Kumar <pa...@gmail.com>
> > wrote:
> >
> > > +1 on EOL branch-1 and all branch-1.x.
> > >
> > > Regards,
> > > Pankaj
> > >
> > > On Thu, Apr 1, 2021 at 3:34 AM Andrew Purtell <ap...@apache.org>
> > wrote:
> > >
> > > > Is it time to consider EOL of branch-1 and all 1.x releases ?
> > > >
> > > > There doesn't seem to be much developer interest in branch-1 beyond
> > > > occasional maintenance. This is understandable. Per our compatibility
> > > > guidelines, branch-1 commits must be compatible with Java 7, and the
> > > range
> > > > of acceptable versions of third party dependencies is also restricted
> > due
> > > > to Java 7 compatibility requirements. Most developers are writing
> code
> > > with
> > > > Java 8+ idioms these days. For that reason and because the branch-1
> > code
> > > > base is generally aged at this point, all but trivial (or lucky!)
> > > backports
> > > > require substantial changes in order to integrate adequately. Let me
> > also
> > > > observe that branch-1 artifacts are not fully compatible with Java 11
> > or
> > > > later. (The shell is a good example of such issues: The version of
> > > > jruby-complete required by branch-1 is not compatible with Java 11
> and
> > > > upgrading to the version used by branch-2 causes shell commands to
> > error
> > > > out due to Ruby language changes.)
> > > >
> > > > We can a priori determine there is insufficient motivation for
> > production
> > > > of release artifacts for the PMC to vote upon. Otherwise, someone
> would
> > > > have done it. We had 12 releases from branch-2 derived code in 2019,
> 13
> > > > releases from branch-2 derived code in 2020, and so far we have had 3
> > > > releases from branch-2 derived code in 2021. In contrast, we had 8
> > > releases
> > > > from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> > and
> > > > so far 0 releases from branch-1 in 2021.
> > > >
> > > > *  2021202020191.x0282.x31312*
> > > >
> > > > If there is someone interested in continuing branch-1, now is the
> time
> > to
> > > > commit. However let me be clear that simply expressing an abstract
> > desire
> > > > to see continued branch-1 releases will not be that useful. It will
> be
> > > > noted, but will not have much real world impact. Apache is a
> do-ocracy.
> > > In
> > > > the absence of intrinsic motivation of project participants, which is
> > > what
> > > > we seem to have here, you will need to do something: Fix the
> > > compatibility
> > > > issues, if any between the last release of 1.x and the current
> branch-1
> > > > head; fix any failing and flaky unit tests; produce release
> artifacts;
> > > and
> > > > submit those artifacts to the PMC for voting. Or, convince someone
> with
> > > > commit rights and/or PMC membership to undertake these actions on
> your
> > > > behalf.
> > > >
> > > > Otherwise, I respectfully submit for your consideration, it is time
> to
> > > > declare  branch-1 and all 1.x code lines EOL, simply acknowledging
> what
> > > has
> > > > effectively already happened.
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > > decrepit hands
> > > >    - A23, Crosstalk
> > > >
> > >
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: EOL branch-1 and all 1.x ?

[Nick Dimiduk <nd...@apache.org>]

Also big +1 from me.

On Thu, Apr 1, 2021 at 09:08 Huaxiang Sun <hu...@gmail.com> wrote:

> Per performance regression concern, we had one such issue for meta when
> upgrading from 1.2 to 2.3.
> It turned out to be default rpc scheduling changed from branch-1 to
> branch-2, and it causes performance regression.


Huaxiang, do you have a JIRA covering this change? What is your suggested
remediation for branch-2 releases? Can/should we make the fix the default
behavior, or is there good reason to keep us running in this “slow mode” by
default, require operators to opt-in to the perf boost?

Thanks,
Nick

On Thu, Apr 1, 2021 at 8:22 AM Pankaj Kumar <pa...@gmail.com>
> wrote:
>
> > +1 on EOL branch-1 and all branch-1.x.
> >
> > Regards,
> > Pankaj
> >
> > On Thu, Apr 1, 2021 at 3:34 AM Andrew Purtell <ap...@apache.org>
> wrote:
> >
> > > Is it time to consider EOL of branch-1 and all 1.x releases ?
> > >
> > > There doesn't seem to be much developer interest in branch-1 beyond
> > > occasional maintenance. This is understandable. Per our compatibility
> > > guidelines, branch-1 commits must be compatible with Java 7, and the
> > range
> > > of acceptable versions of third party dependencies is also restricted
> due
> > > to Java 7 compatibility requirements. Most developers are writing code
> > with
> > > Java 8+ idioms these days. For that reason and because the branch-1
> code
> > > base is generally aged at this point, all but trivial (or lucky!)
> > backports
> > > require substantial changes in order to integrate adequately. Let me
> also
> > > observe that branch-1 artifacts are not fully compatible with Java 11
> or
> > > later. (The shell is a good example of such issues: The version of
> > > jruby-complete required by branch-1 is not compatible with Java 11 and
> > > upgrading to the version used by branch-2 causes shell commands to
> error
> > > out due to Ruby language changes.)
> > >
> > > We can a priori determine there is insufficient motivation for
> production
> > > of release artifacts for the PMC to vote upon. Otherwise, someone would
> > > have done it. We had 12 releases from branch-2 derived code in 2019, 13
> > > releases from branch-2 derived code in 2020, and so far we have had 3
> > > releases from branch-2 derived code in 2021. In contrast, we had 8
> > releases
> > > from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> and
> > > so far 0 releases from branch-1 in 2021.
> > >
> > > *  2021202020191.x0282.x31312*
> > >
> > > If there is someone interested in continuing branch-1, now is the time
> to
> > > commit. However let me be clear that simply expressing an abstract
> desire
> > > to see continued branch-1 releases will not be that useful. It will be
> > > noted, but will not have much real world impact. Apache is a do-ocracy.
> > In
> > > the absence of intrinsic motivation of project participants, which is
> > what
> > > we seem to have here, you will need to do something: Fix the
> > compatibility
> > > issues, if any between the last release of 1.x and the current branch-1
> > > head; fix any failing and flaky unit tests; produce release artifacts;
> > and
> > > submit those artifacts to the PMC for voting. Or, convince someone with
> > > commit rights and/or PMC membership to undertake these actions on your
> > > behalf.
> > >
> > > Otherwise, I respectfully submit for your consideration, it is time to
> > > declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
> > has
> > > effectively already happened.
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> > >
> >
>

Re: EOL branch-1 and all 1.x ?

[Huaxiang Sun <hu...@gmail.com>]

+1 on EOL branch-1 and all branch-1.x.

Per performance regression concern, we had one such issue for meta when
upgrading from 1.2 to 2.3.
It turned out to be default rpc scheduling changed from branch-1 to
branch-2, and it causes performance regression.



On Thu, Apr 1, 2021 at 8:22 AM Pankaj Kumar <pa...@gmail.com>
wrote:

> +1 on EOL branch-1 and all branch-1.x.
>
> Regards,
> Pankaj
>
> On Thu, Apr 1, 2021 at 3:34 AM Andrew Purtell <ap...@apache.org> wrote:
>
> > Is it time to consider EOL of branch-1 and all 1.x releases ?
> >
> > There doesn't seem to be much developer interest in branch-1 beyond
> > occasional maintenance. This is understandable. Per our compatibility
> > guidelines, branch-1 commits must be compatible with Java 7, and the
> range
> > of acceptable versions of third party dependencies is also restricted due
> > to Java 7 compatibility requirements. Most developers are writing code
> with
> > Java 8+ idioms these days. For that reason and because the branch-1 code
> > base is generally aged at this point, all but trivial (or lucky!)
> backports
> > require substantial changes in order to integrate adequately. Let me also
> > observe that branch-1 artifacts are not fully compatible with Java 11 or
> > later. (The shell is a good example of such issues: The version of
> > jruby-complete required by branch-1 is not compatible with Java 11 and
> > upgrading to the version used by branch-2 causes shell commands to error
> > out due to Ruby language changes.)
> >
> > We can a priori determine there is insufficient motivation for production
> > of release artifacts for the PMC to vote upon. Otherwise, someone would
> > have done it. We had 12 releases from branch-2 derived code in 2019, 13
> > releases from branch-2 derived code in 2020, and so far we have had 3
> > releases from branch-2 derived code in 2021. In contrast, we had 8
> releases
> > from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
> > so far 0 releases from branch-1 in 2021.
> >
> > *  2021202020191.x0282.x31312*
> >
> > If there is someone interested in continuing branch-1, now is the time to
> > commit. However let me be clear that simply expressing an abstract desire
> > to see continued branch-1 releases will not be that useful. It will be
> > noted, but will not have much real world impact. Apache is a do-ocracy.
> In
> > the absence of intrinsic motivation of project participants, which is
> what
> > we seem to have here, you will need to do something: Fix the
> compatibility
> > issues, if any between the last release of 1.x and the current branch-1
> > head; fix any failing and flaky unit tests; produce release artifacts;
> and
> > submit those artifacts to the PMC for voting. Or, convince someone with
> > commit rights and/or PMC membership to undertake these actions on your
> > behalf.
> >
> > Otherwise, I respectfully submit for your consideration, it is time to
> > declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
> has
> > effectively already happened.
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>

Re: EOL branch-1 and all 1.x ?

[Pankaj Kumar <pa...@gmail.com>]

+1 on EOL branch-1 and all branch-1.x.

Regards,
Pankaj

On Thu, Apr 1, 2021 at 3:34 AM Andrew Purtell <ap...@apache.org> wrote:

> Is it time to consider EOL of branch-1 and all 1.x releases ?
>
> There doesn't seem to be much developer interest in branch-1 beyond
> occasional maintenance. This is understandable. Per our compatibility
> guidelines, branch-1 commits must be compatible with Java 7, and the range
> of acceptable versions of third party dependencies is also restricted due
> to Java 7 compatibility requirements. Most developers are writing code with
> Java 8+ idioms these days. For that reason and because the branch-1 code
> base is generally aged at this point, all but trivial (or lucky!) backports
> require substantial changes in order to integrate adequately. Let me also
> observe that branch-1 artifacts are not fully compatible with Java 11 or
> later. (The shell is a good example of such issues: The version of
> jruby-complete required by branch-1 is not compatible with Java 11 and
> upgrading to the version used by branch-2 causes shell commands to error
> out due to Ruby language changes.)
>
> We can a priori determine there is insufficient motivation for production
> of release artifacts for the PMC to vote upon. Otherwise, someone would
> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> releases from branch-2 derived code in 2020, and so far we have had 3
> releases from branch-2 derived code in 2021. In contrast, we had 8 releases
> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
> so far 0 releases from branch-1 in 2021.
>
> *  2021202020191.x0282.x31312*
>
> If there is someone interested in continuing branch-1, now is the time to
> commit. However let me be clear that simply expressing an abstract desire
> to see continued branch-1 releases will not be that useful. It will be
> noted, but will not have much real world impact. Apache is a do-ocracy. In
> the absence of intrinsic motivation of project participants, which is what
> we seem to have here, you will need to do something: Fix the compatibility
> issues, if any between the last release of 1.x and the current branch-1
> head; fix any failing and flaky unit tests; produce release artifacts; and
> submit those artifacts to the PMC for voting. Or, convince someone with
> commit rights and/or PMC membership to undertake these actions on your
> behalf.
>
> Otherwise, I respectfully submit for your consideration, it is time to
> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
> effectively already happened.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: EOL branch-1 and all 1.x ?

[Stack <st...@duboce.net>]

Thanks for the write-up Andrew. +1 on its EOL'ing.
S

On Wed, Mar 31, 2021 at 3:03 PM Andrew Purtell <ap...@apache.org> wrote:

> Is it time to consider EOL of branch-1 and all 1.x releases ?
>
> There doesn't seem to be much developer interest in branch-1 beyond
> occasional maintenance. This is understandable. Per our compatibility
> guidelines, branch-1 commits must be compatible with Java 7, and the range
> of acceptable versions of third party dependencies is also restricted due
> to Java 7 compatibility requirements. Most developers are writing code with
> Java 8+ idioms these days. For that reason and because the branch-1 code
> base is generally aged at this point, all but trivial (or lucky!) backports
> require substantial changes in order to integrate adequately. Let me also
> observe that branch-1 artifacts are not fully compatible with Java 11 or
> later. (The shell is a good example of such issues: The version of
> jruby-complete required by branch-1 is not compatible with Java 11 and
> upgrading to the version used by branch-2 causes shell commands to error
> out due to Ruby language changes.)
>
> We can a priori determine there is insufficient motivation for production
> of release artifacts for the PMC to vote upon. Otherwise, someone would
> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> releases from branch-2 derived code in 2020, and so far we have had 3
> releases from branch-2 derived code in 2021. In contrast, we had 8 releases
> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
> so far 0 releases from branch-1 in 2021.
>
> *  2021202020191.x0282.x31312*
>
> If there is someone interested in continuing branch-1, now is the time to
> commit. However let me be clear that simply expressing an abstract desire
> to see continued branch-1 releases will not be that useful. It will be
> noted, but will not have much real world impact. Apache is a do-ocracy. In
> the absence of intrinsic motivation of project participants, which is what
> we seem to have here, you will need to do something: Fix the compatibility
> issues, if any between the last release of 1.x and the current branch-1
> head; fix any failing and flaky unit tests; produce release artifacts; and
> submit those artifacts to the PMC for voting. Or, convince someone with
> commit rights and/or PMC membership to undertake these actions on your
> behalf.
>
> Otherwise, I respectfully submit for your consideration, it is time to
> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
> effectively already happened.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: EOL branch-1 and all 1.x ?

[Reid Chan <re...@gmail.com>]

FYI, a JDK issue when I was making the 1.7.0 release.

https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E


---
Best Regards,
R.C

On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:

> Is it time to consider EOL of branch-1 and all 1.x releases ?
>
> There doesn't seem to be much developer interest in branch-1 beyond
> occasional maintenance. This is understandable. Per our compatibility
> guidelines, branch-1 commits must be compatible with Java 7, and the range
> of acceptable versions of third party dependencies is also restricted due
> to Java 7 compatibility requirements. Most developers are writing code with
> Java 8+ idioms these days. For that reason and because the branch-1 code
> base is generally aged at this point, all but trivial (or lucky!) backports
> require substantial changes in order to integrate adequately. Let me also
> observe that branch-1 artifacts are not fully compatible with Java 11 or
> later. (The shell is a good example of such issues: The version of
> jruby-complete required by branch-1 is not compatible with Java 11 and
> upgrading to the version used by branch-2 causes shell commands to error
> out due to Ruby language changes.)
>
> We can a priori determine there is insufficient motivation for production
> of release artifacts for the PMC to vote upon. Otherwise, someone would
> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> releases from branch-2 derived code in 2020, and so far we have had 3
> releases from branch-2 derived code in 2021. In contrast, we had 8 releases
> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
> so far 0 releases from branch-1 in 2021.
>
> *  2021202020191.x0282.x31312*
>
> If there is someone interested in continuing branch-1, now is the time to
> commit. However let me be clear that simply expressing an abstract desire
> to see continued branch-1 releases will not be that useful. It will be
> noted, but will not have much real world impact. Apache is a do-ocracy. In
> the absence of intrinsic motivation of project participants, which is what
> we seem to have here, you will need to do something: Fix the compatibility
> issues, if any between the last release of 1.x and the current branch-1
> head; fix any failing and flaky unit tests; produce release artifacts; and
> submit those artifacts to the PMC for voting. Or, convince someone with
> commit rights and/or PMC membership to undertake these actions on your
> behalf.
>
> Otherwise, I respectfully submit for your consideration, it is time to
> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
> effectively already happened.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

回复： EOL branch-1 and all 1.x ?

[zheng wang <18...@qq.com>]

+1 on EOL.




------------------ 原始邮件 ------------------
发件人:                                                                                                                        "user"                                                                                    <psomogyi@apache.org&gt;;
发送时间:&nbsp;2021年4月1日(星期四) 晚上9:24
收件人:&nbsp;"HBase Dev List"<dev@hbase.apache.org&gt;;
抄送:&nbsp;"hbase-user"<user@hbase.apache.org&gt;;
主题:&nbsp;Re: EOL branch-1 and all 1.x ?



+1 on EOL.

On Thu, Apr 1, 2021 at 7:32 AM Viraj Jasani <vjasani@apache.org&gt; wrote:

&gt; +1 to EOL'ing branch-1 and all other branch-1.x too (if they are still
&gt; active at all)
&gt;
&gt;
&gt; On Thu, 1 Apr 2021 at 8:53 AM, Andrew Purtell <andrew.purtell@gmail.com&gt;
&gt; wrote:
&gt;
&gt; &gt; EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be
&gt; &gt; fine to leave that in place. That can be a separate, future, discussion,
&gt; &gt; although if branch-1 becomes EOL its eventual removal would be certain.
&gt; The
&gt; &gt; question is really if we plan to maintain branch-1 going forward. Based
&gt; on
&gt; &gt; lack of interest and demand in releasing it, there does not seem reason
&gt; to.
&gt; &gt;
&gt; &gt;
&gt; &gt; &gt; On Mar 31, 2021, at 7:51 PM, Reid Chan <reidchan0301@gmail.com&gt; wrote:
&gt; &gt; &gt;
&gt; &gt; &gt; My only concern is about the performance, once in a while there'll be
&gt; &gt; &gt; some emails like "2.x.y is slower than 1.x.y".
&gt; &gt; &gt;
&gt; &gt; &gt;
&gt; &gt; &gt;&gt; On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <apurtell@apache.org&gt;
&gt; &gt; wrote:
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; Is it time to consider EOL of branch-1 and all 1.x releases ?
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; There doesn't seem to be much developer interest in branch-1 beyond
&gt; &gt; &gt;&gt; occasional maintenance. This is understandable. Per our compatibility
&gt; &gt; &gt;&gt; guidelines, branch-1 commits must be compatible with Java 7, and the
&gt; &gt; range
&gt; &gt; &gt;&gt; of acceptable versions of third party dependencies is also restricted
&gt; &gt; due
&gt; &gt; &gt;&gt; to Java 7 compatibility requirements. Most developers are writing code
&gt; &gt; with
&gt; &gt; &gt;&gt; Java 8+ idioms these days. For that reason and because the branch-1
&gt; code
&gt; &gt; &gt;&gt; base is generally aged at this point, all but trivial (or lucky!)
&gt; &gt; backports
&gt; &gt; &gt;&gt; require substantial changes in order to integrate adequately. Let me
&gt; &gt; also
&gt; &gt; &gt;&gt; observe that branch-1 artifacts are not fully compatible with Java 11
&gt; or
&gt; &gt; &gt;&gt; later. (The shell is a good example of such issues: The version of
&gt; &gt; &gt;&gt; jruby-complete required by branch-1 is not compatible with Java 11 and
&gt; &gt; &gt;&gt; upgrading to the version used by branch-2 causes shell commands to
&gt; error
&gt; &gt; &gt;&gt; out due to Ruby language changes.)
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; We can a priori determine there is insufficient motivation for
&gt; &gt; production
&gt; &gt; &gt;&gt; of release artifacts for the PMC to vote upon. Otherwise, someone
&gt; would
&gt; &gt; &gt;&gt; have done it. We had 12 releases from branch-2 derived code in 2019,
&gt; 13
&gt; &gt; &gt;&gt; releases from branch-2 derived code in 2020, and so far we have had 3
&gt; &gt; &gt;&gt; releases from branch-2 derived code in 2021. In contrast, we had 8
&gt; &gt; releases
&gt; &gt; &gt;&gt; from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
&gt; &gt; and
&gt; &gt; &gt;&gt; so far 0 releases from branch-1 in 2021.
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; *&nbsp; 2021202020191.x0282.x31312*
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; If there is someone interested in continuing branch-1, now is the time
&gt; &gt; to
&gt; &gt; &gt;&gt; commit. However let me be clear that simply expressing an abstract
&gt; &gt; desire
&gt; &gt; &gt;&gt; to see continued branch-1 releases will not be that useful. It will be
&gt; &gt; &gt;&gt; noted, but will not have much real world impact. Apache is a
&gt; do-ocracy.
&gt; &gt; In
&gt; &gt; &gt;&gt; the absence of intrinsic motivation of project participants, which is
&gt; &gt; what
&gt; &gt; &gt;&gt; we seem to have here, you will need to do something: Fix the
&gt; &gt; compatibility
&gt; &gt; &gt;&gt; issues, if any between the last release of 1.x and the current
&gt; branch-1
&gt; &gt; &gt;&gt; head; fix any failing and flaky unit tests; produce release artifacts;
&gt; &gt; and
&gt; &gt; &gt;&gt; submit those artifacts to the PMC for voting. Or, convince someone
&gt; with
&gt; &gt; &gt;&gt; commit rights and/or PMC membership to undertake these actions on your
&gt; &gt; &gt;&gt; behalf.
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; Otherwise, I respectfully submit for your consideration, it is time to
&gt; &gt; &gt;&gt; declare&nbsp; branch-1 and all 1.x code lines EOL, simply acknowledging
&gt; what
&gt; &gt; has
&gt; &gt; &gt;&gt; effectively already happened.
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; --
&gt; &gt; &gt;&gt; Best regards,
&gt; &gt; &gt;&gt; Andrew
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; Words like orphans lost among the crosstalk, meaning torn from truth's
&gt; &gt; &gt;&gt; decrepit hands
&gt; &gt; &gt;&gt;&nbsp;&nbsp; - A23, Crosstalk
&gt; &gt; &gt;&gt;
&gt; &gt;
&gt;

回复： EOL branch-1 and all 1.x ?

[zheng wang <18...@qq.com>]

+1 on EOL.




------------------ 原始邮件 ------------------
发件人:                                                                                                                        "user"                                                                                    <psomogyi@apache.org&gt;;
发送时间:&nbsp;2021年4月1日(星期四) 晚上9:24
收件人:&nbsp;"HBase Dev List"<dev@hbase.apache.org&gt;;
抄送:&nbsp;"hbase-user"<user@hbase.apache.org&gt;;
主题:&nbsp;Re: EOL branch-1 and all 1.x ?



+1 on EOL.

On Thu, Apr 1, 2021 at 7:32 AM Viraj Jasani <vjasani@apache.org&gt; wrote:

&gt; +1 to EOL'ing branch-1 and all other branch-1.x too (if they are still
&gt; active at all)
&gt;
&gt;
&gt; On Thu, 1 Apr 2021 at 8:53 AM, Andrew Purtell <andrew.purtell@gmail.com&gt;
&gt; wrote:
&gt;
&gt; &gt; EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be
&gt; &gt; fine to leave that in place. That can be a separate, future, discussion,
&gt; &gt; although if branch-1 becomes EOL its eventual removal would be certain.
&gt; The
&gt; &gt; question is really if we plan to maintain branch-1 going forward. Based
&gt; on
&gt; &gt; lack of interest and demand in releasing it, there does not seem reason
&gt; to.
&gt; &gt;
&gt; &gt;
&gt; &gt; &gt; On Mar 31, 2021, at 7:51 PM, Reid Chan <reidchan0301@gmail.com&gt; wrote:
&gt; &gt; &gt;
&gt; &gt; &gt; My only concern is about the performance, once in a while there'll be
&gt; &gt; &gt; some emails like "2.x.y is slower than 1.x.y".
&gt; &gt; &gt;
&gt; &gt; &gt;
&gt; &gt; &gt;&gt; On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <apurtell@apache.org&gt;
&gt; &gt; wrote:
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; Is it time to consider EOL of branch-1 and all 1.x releases ?
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; There doesn't seem to be much developer interest in branch-1 beyond
&gt; &gt; &gt;&gt; occasional maintenance. This is understandable. Per our compatibility
&gt; &gt; &gt;&gt; guidelines, branch-1 commits must be compatible with Java 7, and the
&gt; &gt; range
&gt; &gt; &gt;&gt; of acceptable versions of third party dependencies is also restricted
&gt; &gt; due
&gt; &gt; &gt;&gt; to Java 7 compatibility requirements. Most developers are writing code
&gt; &gt; with
&gt; &gt; &gt;&gt; Java 8+ idioms these days. For that reason and because the branch-1
&gt; code
&gt; &gt; &gt;&gt; base is generally aged at this point, all but trivial (or lucky!)
&gt; &gt; backports
&gt; &gt; &gt;&gt; require substantial changes in order to integrate adequately. Let me
&gt; &gt; also
&gt; &gt; &gt;&gt; observe that branch-1 artifacts are not fully compatible with Java 11
&gt; or
&gt; &gt; &gt;&gt; later. (The shell is a good example of such issues: The version of
&gt; &gt; &gt;&gt; jruby-complete required by branch-1 is not compatible with Java 11 and
&gt; &gt; &gt;&gt; upgrading to the version used by branch-2 causes shell commands to
&gt; error
&gt; &gt; &gt;&gt; out due to Ruby language changes.)
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; We can a priori determine there is insufficient motivation for
&gt; &gt; production
&gt; &gt; &gt;&gt; of release artifacts for the PMC to vote upon. Otherwise, someone
&gt; would
&gt; &gt; &gt;&gt; have done it. We had 12 releases from branch-2 derived code in 2019,
&gt; 13
&gt; &gt; &gt;&gt; releases from branch-2 derived code in 2020, and so far we have had 3
&gt; &gt; &gt;&gt; releases from branch-2 derived code in 2021. In contrast, we had 8
&gt; &gt; releases
&gt; &gt; &gt;&gt; from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
&gt; &gt; and
&gt; &gt; &gt;&gt; so far 0 releases from branch-1 in 2021.
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; *&nbsp; 2021202020191.x0282.x31312*
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; If there is someone interested in continuing branch-1, now is the time
&gt; &gt; to
&gt; &gt; &gt;&gt; commit. However let me be clear that simply expressing an abstract
&gt; &gt; desire
&gt; &gt; &gt;&gt; to see continued branch-1 releases will not be that useful. It will be
&gt; &gt; &gt;&gt; noted, but will not have much real world impact. Apache is a
&gt; do-ocracy.
&gt; &gt; In
&gt; &gt; &gt;&gt; the absence of intrinsic motivation of project participants, which is
&gt; &gt; what
&gt; &gt; &gt;&gt; we seem to have here, you will need to do something: Fix the
&gt; &gt; compatibility
&gt; &gt; &gt;&gt; issues, if any between the last release of 1.x and the current
&gt; branch-1
&gt; &gt; &gt;&gt; head; fix any failing and flaky unit tests; produce release artifacts;
&gt; &gt; and
&gt; &gt; &gt;&gt; submit those artifacts to the PMC for voting. Or, convince someone
&gt; with
&gt; &gt; &gt;&gt; commit rights and/or PMC membership to undertake these actions on your
&gt; &gt; &gt;&gt; behalf.
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; Otherwise, I respectfully submit for your consideration, it is time to
&gt; &gt; &gt;&gt; declare&nbsp; branch-1 and all 1.x code lines EOL, simply acknowledging
&gt; what
&gt; &gt; has
&gt; &gt; &gt;&gt; effectively already happened.
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; --
&gt; &gt; &gt;&gt; Best regards,
&gt; &gt; &gt;&gt; Andrew
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; Words like orphans lost among the crosstalk, meaning torn from truth's
&gt; &gt; &gt;&gt; decrepit hands
&gt; &gt; &gt;&gt;&nbsp;&nbsp; - A23, Crosstalk
&gt; &gt; &gt;&gt;
&gt; &gt;
&gt;

Re: EOL branch-1 and all 1.x ?

[Peter Somogyi <ps...@apache.org>]

+1 on EOL.

On Thu, Apr 1, 2021 at 7:32 AM Viraj Jasani <vj...@apache.org> wrote:

> +1 to EOL'ing branch-1 and all other branch-1.x too (if they are still
> active at all)
>
>
> On Thu, 1 Apr 2021 at 8:53 AM, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be
> > fine to leave that in place. That can be a separate, future, discussion,
> > although if branch-1 becomes EOL its eventual removal would be certain.
> The
> > question is really if we plan to maintain branch-1 going forward. Based
> on
> > lack of interest and demand in releasing it, there does not seem reason
> to.
> >
> >
> > > On Mar 31, 2021, at 7:51 PM, Reid Chan <re...@gmail.com> wrote:
> > >
> > > My only concern is about the performance, once in a while there'll be
> > > some emails like "2.x.y is slower than 1.x.y".
> > >
> > >
> > >> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
> > wrote:
> > >>
> > >> Is it time to consider EOL of branch-1 and all 1.x releases ?
> > >>
> > >> There doesn't seem to be much developer interest in branch-1 beyond
> > >> occasional maintenance. This is understandable. Per our compatibility
> > >> guidelines, branch-1 commits must be compatible with Java 7, and the
> > range
> > >> of acceptable versions of third party dependencies is also restricted
> > due
> > >> to Java 7 compatibility requirements. Most developers are writing code
> > with
> > >> Java 8+ idioms these days. For that reason and because the branch-1
> code
> > >> base is generally aged at this point, all but trivial (or lucky!)
> > backports
> > >> require substantial changes in order to integrate adequately. Let me
> > also
> > >> observe that branch-1 artifacts are not fully compatible with Java 11
> or
> > >> later. (The shell is a good example of such issues: The version of
> > >> jruby-complete required by branch-1 is not compatible with Java 11 and
> > >> upgrading to the version used by branch-2 causes shell commands to
> error
> > >> out due to Ruby language changes.)
> > >>
> > >> We can a priori determine there is insufficient motivation for
> > production
> > >> of release artifacts for the PMC to vote upon. Otherwise, someone
> would
> > >> have done it. We had 12 releases from branch-2 derived code in 2019,
> 13
> > >> releases from branch-2 derived code in 2020, and so far we have had 3
> > >> releases from branch-2 derived code in 2021. In contrast, we had 8
> > releases
> > >> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> > and
> > >> so far 0 releases from branch-1 in 2021.
> > >>
> > >> *  2021202020191.x0282.x31312*
> > >>
> > >> If there is someone interested in continuing branch-1, now is the time
> > to
> > >> commit. However let me be clear that simply expressing an abstract
> > desire
> > >> to see continued branch-1 releases will not be that useful. It will be
> > >> noted, but will not have much real world impact. Apache is a
> do-ocracy.
> > In
> > >> the absence of intrinsic motivation of project participants, which is
> > what
> > >> we seem to have here, you will need to do something: Fix the
> > compatibility
> > >> issues, if any between the last release of 1.x and the current
> branch-1
> > >> head; fix any failing and flaky unit tests; produce release artifacts;
> > and
> > >> submit those artifacts to the PMC for voting. Or, convince someone
> with
> > >> commit rights and/or PMC membership to undertake these actions on your
> > >> behalf.
> > >>
> > >> Otherwise, I respectfully submit for your consideration, it is time to
> > >> declare  branch-1 and all 1.x code lines EOL, simply acknowledging
> what
> > has
> > >> effectively already happened.
> > >>
> > >> --
> > >> Best regards,
> > >> Andrew
> > >>
> > >> Words like orphans lost among the crosstalk, meaning torn from truth's
> > >> decrepit hands
> > >>   - A23, Crosstalk
> > >>
> >
>

Re: EOL branch-1 and all 1.x ?

[Peter Somogyi <ps...@apache.org>]

+1 on EOL.

On Thu, Apr 1, 2021 at 7:32 AM Viraj Jasani <vj...@apache.org> wrote:

> +1 to EOL'ing branch-1 and all other branch-1.x too (if they are still
> active at all)
>
>
> On Thu, 1 Apr 2021 at 8:53 AM, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be
> > fine to leave that in place. That can be a separate, future, discussion,
> > although if branch-1 becomes EOL its eventual removal would be certain.
> The
> > question is really if we plan to maintain branch-1 going forward. Based
> on
> > lack of interest and demand in releasing it, there does not seem reason
> to.
> >
> >
> > > On Mar 31, 2021, at 7:51 PM, Reid Chan <re...@gmail.com> wrote:
> > >
> > > My only concern is about the performance, once in a while there'll be
> > > some emails like "2.x.y is slower than 1.x.y".
> > >
> > >
> > >> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
> > wrote:
> > >>
> > >> Is it time to consider EOL of branch-1 and all 1.x releases ?
> > >>
> > >> There doesn't seem to be much developer interest in branch-1 beyond
> > >> occasional maintenance. This is understandable. Per our compatibility
> > >> guidelines, branch-1 commits must be compatible with Java 7, and the
> > range
> > >> of acceptable versions of third party dependencies is also restricted
> > due
> > >> to Java 7 compatibility requirements. Most developers are writing code
> > with
> > >> Java 8+ idioms these days. For that reason and because the branch-1
> code
> > >> base is generally aged at this point, all but trivial (or lucky!)
> > backports
> > >> require substantial changes in order to integrate adequately. Let me
> > also
> > >> observe that branch-1 artifacts are not fully compatible with Java 11
> or
> > >> later. (The shell is a good example of such issues: The version of
> > >> jruby-complete required by branch-1 is not compatible with Java 11 and
> > >> upgrading to the version used by branch-2 causes shell commands to
> error
> > >> out due to Ruby language changes.)
> > >>
> > >> We can a priori determine there is insufficient motivation for
> > production
> > >> of release artifacts for the PMC to vote upon. Otherwise, someone
> would
> > >> have done it. We had 12 releases from branch-2 derived code in 2019,
> 13
> > >> releases from branch-2 derived code in 2020, and so far we have had 3
> > >> releases from branch-2 derived code in 2021. In contrast, we had 8
> > releases
> > >> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> > and
> > >> so far 0 releases from branch-1 in 2021.
> > >>
> > >> *  2021202020191.x0282.x31312*
> > >>
> > >> If there is someone interested in continuing branch-1, now is the time
> > to
> > >> commit. However let me be clear that simply expressing an abstract
> > desire
> > >> to see continued branch-1 releases will not be that useful. It will be
> > >> noted, but will not have much real world impact. Apache is a
> do-ocracy.
> > In
> > >> the absence of intrinsic motivation of project participants, which is
> > what
> > >> we seem to have here, you will need to do something: Fix the
> > compatibility
> > >> issues, if any between the last release of 1.x and the current
> branch-1
> > >> head; fix any failing and flaky unit tests; produce release artifacts;
> > and
> > >> submit those artifacts to the PMC for voting. Or, convince someone
> with
> > >> commit rights and/or PMC membership to undertake these actions on your
> > >> behalf.
> > >>
> > >> Otherwise, I respectfully submit for your consideration, it is time to
> > >> declare  branch-1 and all 1.x code lines EOL, simply acknowledging
> what
> > has
> > >> effectively already happened.
> > >>
> > >> --
> > >> Best regards,
> > >> Andrew
> > >>
> > >> Words like orphans lost among the crosstalk, meaning torn from truth's
> > >> decrepit hands
> > >>   - A23, Crosstalk
> > >>
> >
>

Re: EOL branch-1 and all 1.x ?

[Viraj Jasani <vj...@apache.org>]

+1 to EOL'ing branch-1 and all other branch-1.x too (if they are still
active at all)


On Thu, 1 Apr 2021 at 8:53 AM, Andrew Purtell <an...@gmail.com>
wrote:

> EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be
> fine to leave that in place. That can be a separate, future, discussion,
> although if branch-1 becomes EOL its eventual removal would be certain. The
> question is really if we plan to maintain branch-1 going forward. Based on
> lack of interest and demand in releasing it, there does not seem reason to.
>
>
> > On Mar 31, 2021, at 7:51 PM, Reid Chan <re...@gmail.com> wrote:
> >
> > My only concern is about the performance, once in a while there'll be
> > some emails like "2.x.y is slower than 1.x.y".
> >
> >
> >> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
> wrote:
> >>
> >> Is it time to consider EOL of branch-1 and all 1.x releases ?
> >>
> >> There doesn't seem to be much developer interest in branch-1 beyond
> >> occasional maintenance. This is understandable. Per our compatibility
> >> guidelines, branch-1 commits must be compatible with Java 7, and the
> range
> >> of acceptable versions of third party dependencies is also restricted
> due
> >> to Java 7 compatibility requirements. Most developers are writing code
> with
> >> Java 8+ idioms these days. For that reason and because the branch-1 code
> >> base is generally aged at this point, all but trivial (or lucky!)
> backports
> >> require substantial changes in order to integrate adequately. Let me
> also
> >> observe that branch-1 artifacts are not fully compatible with Java 11 or
> >> later. (The shell is a good example of such issues: The version of
> >> jruby-complete required by branch-1 is not compatible with Java 11 and
> >> upgrading to the version used by branch-2 causes shell commands to error
> >> out due to Ruby language changes.)
> >>
> >> We can a priori determine there is insufficient motivation for
> production
> >> of release artifacts for the PMC to vote upon. Otherwise, someone would
> >> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> >> releases from branch-2 derived code in 2020, and so far we have had 3
> >> releases from branch-2 derived code in 2021. In contrast, we had 8
> releases
> >> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> and
> >> so far 0 releases from branch-1 in 2021.
> >>
> >> *  2021202020191.x0282.x31312*
> >>
> >> If there is someone interested in continuing branch-1, now is the time
> to
> >> commit. However let me be clear that simply expressing an abstract
> desire
> >> to see continued branch-1 releases will not be that useful. It will be
> >> noted, but will not have much real world impact. Apache is a do-ocracy.
> In
> >> the absence of intrinsic motivation of project participants, which is
> what
> >> we seem to have here, you will need to do something: Fix the
> compatibility
> >> issues, if any between the last release of 1.x and the current branch-1
> >> head; fix any failing and flaky unit tests; produce release artifacts;
> and
> >> submit those artifacts to the PMC for voting. Or, convince someone with
> >> commit rights and/or PMC membership to undertake these actions on your
> >> behalf.
> >>
> >> Otherwise, I respectfully submit for your consideration, it is time to
> >> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
> has
> >> effectively already happened.
> >>
> >> --
> >> Best regards,
> >> Andrew
> >>
> >> Words like orphans lost among the crosstalk, meaning torn from truth's
> >> decrepit hands
> >>   - A23, Crosstalk
> >>
>

Re: EOL branch-1 and all 1.x ?

[Viraj Jasani <vj...@apache.org>]

+1 to EOL'ing branch-1 and all other branch-1.x too (if they are still
active at all)


On Thu, 1 Apr 2021 at 8:53 AM, Andrew Purtell <an...@gmail.com>
wrote:

> EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be
> fine to leave that in place. That can be a separate, future, discussion,
> although if branch-1 becomes EOL its eventual removal would be certain. The
> question is really if we plan to maintain branch-1 going forward. Based on
> lack of interest and demand in releasing it, there does not seem reason to.
>
>
> > On Mar 31, 2021, at 7:51 PM, Reid Chan <re...@gmail.com> wrote:
> >
> > My only concern is about the performance, once in a while there'll be
> > some emails like "2.x.y is slower than 1.x.y".
> >
> >
> >> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org>
> wrote:
> >>
> >> Is it time to consider EOL of branch-1 and all 1.x releases ?
> >>
> >> There doesn't seem to be much developer interest in branch-1 beyond
> >> occasional maintenance. This is understandable. Per our compatibility
> >> guidelines, branch-1 commits must be compatible with Java 7, and the
> range
> >> of acceptable versions of third party dependencies is also restricted
> due
> >> to Java 7 compatibility requirements. Most developers are writing code
> with
> >> Java 8+ idioms these days. For that reason and because the branch-1 code
> >> base is generally aged at this point, all but trivial (or lucky!)
> backports
> >> require substantial changes in order to integrate adequately. Let me
> also
> >> observe that branch-1 artifacts are not fully compatible with Java 11 or
> >> later. (The shell is a good example of such issues: The version of
> >> jruby-complete required by branch-1 is not compatible with Java 11 and
> >> upgrading to the version used by branch-2 causes shell commands to error
> >> out due to Ruby language changes.)
> >>
> >> We can a priori determine there is insufficient motivation for
> production
> >> of release artifacts for the PMC to vote upon. Otherwise, someone would
> >> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> >> releases from branch-2 derived code in 2020, and so far we have had 3
> >> releases from branch-2 derived code in 2021. In contrast, we had 8
> releases
> >> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> and
> >> so far 0 releases from branch-1 in 2021.
> >>
> >> *  2021202020191.x0282.x31312*
> >>
> >> If there is someone interested in continuing branch-1, now is the time
> to
> >> commit. However let me be clear that simply expressing an abstract
> desire
> >> to see continued branch-1 releases will not be that useful. It will be
> >> noted, but will not have much real world impact. Apache is a do-ocracy.
> In
> >> the absence of intrinsic motivation of project participants, which is
> what
> >> we seem to have here, you will need to do something: Fix the
> compatibility
> >> issues, if any between the last release of 1.x and the current branch-1
> >> head; fix any failing and flaky unit tests; produce release artifacts;
> and
> >> submit those artifacts to the PMC for voting. Or, convince someone with
> >> commit rights and/or PMC membership to undertake these actions on your
> >> behalf.
> >>
> >> Otherwise, I respectfully submit for your consideration, it is time to
> >> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what
> has
> >> effectively already happened.
> >>
> >> --
> >> Best regards,
> >> Andrew
> >>
> >> Words like orphans lost among the crosstalk, meaning torn from truth's
> >> decrepit hands
> >>   - A23, Crosstalk
> >>
>

Re: EOL branch-1 and all 1.x ?

[Andrew Purtell <an...@gmail.com>]

EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be fine to leave that in place. That can be a separate, future, discussion, although if branch-1 becomes EOL its eventual removal would be certain. The question is really if we plan to maintain branch-1 going forward. Based on lack of interest and demand in releasing it, there does not seem reason to. 


> On Mar 31, 2021, at 7:51 PM, Reid Chan <re...@gmail.com> wrote:
> 
> My only concern is about the performance, once in a while there'll be
> some emails like "2.x.y is slower than 1.x.y".
> 
> 
>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:
>> 
>> Is it time to consider EOL of branch-1 and all 1.x releases ?
>> 
>> There doesn't seem to be much developer interest in branch-1 beyond
>> occasional maintenance. This is understandable. Per our compatibility
>> guidelines, branch-1 commits must be compatible with Java 7, and the range
>> of acceptable versions of third party dependencies is also restricted due
>> to Java 7 compatibility requirements. Most developers are writing code with
>> Java 8+ idioms these days. For that reason and because the branch-1 code
>> base is generally aged at this point, all but trivial (or lucky!) backports
>> require substantial changes in order to integrate adequately. Let me also
>> observe that branch-1 artifacts are not fully compatible with Java 11 or
>> later. (The shell is a good example of such issues: The version of
>> jruby-complete required by branch-1 is not compatible with Java 11 and
>> upgrading to the version used by branch-2 causes shell commands to error
>> out due to Ruby language changes.)
>> 
>> We can a priori determine there is insufficient motivation for production
>> of release artifacts for the PMC to vote upon. Otherwise, someone would
>> have done it. We had 12 releases from branch-2 derived code in 2019, 13
>> releases from branch-2 derived code in 2020, and so far we have had 3
>> releases from branch-2 derived code in 2021. In contrast, we had 8 releases
>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
>> so far 0 releases from branch-1 in 2021.
>> 
>> *  2021202020191.x0282.x31312*
>> 
>> If there is someone interested in continuing branch-1, now is the time to
>> commit. However let me be clear that simply expressing an abstract desire
>> to see continued branch-1 releases will not be that useful. It will be
>> noted, but will not have much real world impact. Apache is a do-ocracy. In
>> the absence of intrinsic motivation of project participants, which is what
>> we seem to have here, you will need to do something: Fix the compatibility
>> issues, if any between the last release of 1.x and the current branch-1
>> head; fix any failing and flaky unit tests; produce release artifacts; and
>> submit those artifacts to the PMC for voting. Or, convince someone with
>> commit rights and/or PMC membership to undertake these actions on your
>> behalf.
>> 
>> Otherwise, I respectfully submit for your consideration, it is time to
>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
>> effectively already happened.
>> 
>> --
>> Best regards,
>> Andrew
>> 
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>   - A23, Crosstalk
>> 

Re: EOL branch-1 and all 1.x ?

[Andrew Purtell <an...@gmail.com>]

EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be fine to leave that in place. That can be a separate, future, discussion, although if branch-1 becomes EOL its eventual removal would be certain. The question is really if we plan to maintain branch-1 going forward. Based on lack of interest and demand in releasing it, there does not seem reason to. 


> On Mar 31, 2021, at 7:51 PM, Reid Chan <re...@gmail.com> wrote:
> 
> My only concern is about the performance, once in a while there'll be
> some emails like "2.x.y is slower than 1.x.y".
> 
> 
>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:
>> 
>> Is it time to consider EOL of branch-1 and all 1.x releases ?
>> 
>> There doesn't seem to be much developer interest in branch-1 beyond
>> occasional maintenance. This is understandable. Per our compatibility
>> guidelines, branch-1 commits must be compatible with Java 7, and the range
>> of acceptable versions of third party dependencies is also restricted due
>> to Java 7 compatibility requirements. Most developers are writing code with
>> Java 8+ idioms these days. For that reason and because the branch-1 code
>> base is generally aged at this point, all but trivial (or lucky!) backports
>> require substantial changes in order to integrate adequately. Let me also
>> observe that branch-1 artifacts are not fully compatible with Java 11 or
>> later. (The shell is a good example of such issues: The version of
>> jruby-complete required by branch-1 is not compatible with Java 11 and
>> upgrading to the version used by branch-2 causes shell commands to error
>> out due to Ruby language changes.)
>> 
>> We can a priori determine there is insufficient motivation for production
>> of release artifacts for the PMC to vote upon. Otherwise, someone would
>> have done it. We had 12 releases from branch-2 derived code in 2019, 13
>> releases from branch-2 derived code in 2020, and so far we have had 3
>> releases from branch-2 derived code in 2021. In contrast, we had 8 releases
>> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
>> so far 0 releases from branch-1 in 2021.
>> 
>> *  2021202020191.x0282.x31312*
>> 
>> If there is someone interested in continuing branch-1, now is the time to
>> commit. However let me be clear that simply expressing an abstract desire
>> to see continued branch-1 releases will not be that useful. It will be
>> noted, but will not have much real world impact. Apache is a do-ocracy. In
>> the absence of intrinsic motivation of project participants, which is what
>> we seem to have here, you will need to do something: Fix the compatibility
>> issues, if any between the last release of 1.x and the current branch-1
>> head; fix any failing and flaky unit tests; produce release artifacts; and
>> submit those artifacts to the PMC for voting. Or, convince someone with
>> commit rights and/or PMC membership to undertake these actions on your
>> behalf.
>> 
>> Otherwise, I respectfully submit for your consideration, it is time to
>> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
>> effectively already happened.
>> 
>> --
>> Best regards,
>> Andrew
>> 
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>   - A23, Crosstalk
>> 

Re: EOL branch-1 and all 1.x ?

[Reid Chan <re...@gmail.com>]

My only concern is about the performance, once in a while there'll be
some emails like "2.x.y is slower than 1.x.y".


On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:

> Is it time to consider EOL of branch-1 and all 1.x releases ?
>
> There doesn't seem to be much developer interest in branch-1 beyond
> occasional maintenance. This is understandable. Per our compatibility
> guidelines, branch-1 commits must be compatible with Java 7, and the range
> of acceptable versions of third party dependencies is also restricted due
> to Java 7 compatibility requirements. Most developers are writing code with
> Java 8+ idioms these days. For that reason and because the branch-1 code
> base is generally aged at this point, all but trivial (or lucky!) backports
> require substantial changes in order to integrate adequately. Let me also
> observe that branch-1 artifacts are not fully compatible with Java 11 or
> later. (The shell is a good example of such issues: The version of
> jruby-complete required by branch-1 is not compatible with Java 11 and
> upgrading to the version used by branch-2 causes shell commands to error
> out due to Ruby language changes.)
>
> We can a priori determine there is insufficient motivation for production
> of release artifacts for the PMC to vote upon. Otherwise, someone would
> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> releases from branch-2 derived code in 2020, and so far we have had 3
> releases from branch-2 derived code in 2021. In contrast, we had 8 releases
> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
> so far 0 releases from branch-1 in 2021.
>
> *  2021202020191.x0282.x31312*
>
> If there is someone interested in continuing branch-1, now is the time to
> commit. However let me be clear that simply expressing an abstract desire
> to see continued branch-1 releases will not be that useful. It will be
> noted, but will not have much real world impact. Apache is a do-ocracy. In
> the absence of intrinsic motivation of project participants, which is what
> we seem to have here, you will need to do something: Fix the compatibility
> issues, if any between the last release of 1.x and the current branch-1
> head; fix any failing and flaky unit tests; produce release artifacts; and
> submit those artifacts to the PMC for voting. Or, convince someone with
> commit rights and/or PMC membership to undertake these actions on your
> behalf.
>
> Otherwise, I respectfully submit for your consideration, it is time to
> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
> effectively already happened.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>

Re: EOL branch-1 and all 1.x ?

[Reid Chan <re...@gmail.com>]

My only concern is about the performance, once in a while there'll be
some emails like "2.x.y is slower than 1.x.y".


On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <ap...@apache.org> wrote:

> Is it time to consider EOL of branch-1 and all 1.x releases ?
>
> There doesn't seem to be much developer interest in branch-1 beyond
> occasional maintenance. This is understandable. Per our compatibility
> guidelines, branch-1 commits must be compatible with Java 7, and the range
> of acceptable versions of third party dependencies is also restricted due
> to Java 7 compatibility requirements. Most developers are writing code with
> Java 8+ idioms these days. For that reason and because the branch-1 code
> base is generally aged at this point, all but trivial (or lucky!) backports
> require substantial changes in order to integrate adequately. Let me also
> observe that branch-1 artifacts are not fully compatible with Java 11 or
> later. (The shell is a good example of such issues: The version of
> jruby-complete required by branch-1 is not compatible with Java 11 and
> upgrading to the version used by branch-2 causes shell commands to error
> out due to Ruby language changes.)
>
> We can a priori determine there is insufficient motivation for production
> of release artifacts for the PMC to vote upon. Otherwise, someone would
> have done it. We had 12 releases from branch-2 derived code in 2019, 13
> releases from branch-2 derived code in 2020, and so far we have had 3
> releases from branch-2 derived code in 2021. In contrast, we had 8 releases
> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020, and
> so far 0 releases from branch-1 in 2021.
>
> *  2021202020191.x0282.x31312*
>
> If there is someone interested in continuing branch-1, now is the time to
> commit. However let me be clear that simply expressing an abstract desire
> to see continued branch-1 releases will not be that useful. It will be
> noted, but will not have much real world impact. Apache is a do-ocracy. In
> the absence of intrinsic motivation of project participants, which is what
> we seem to have here, you will need to do something: Fix the compatibility
> issues, if any between the last release of 1.x and the current branch-1
> head; fix any failing and flaky unit tests; produce release artifacts; and
> submit those artifacts to the PMC for voting. Or, convince someone with
> commit rights and/or PMC membership to undertake these actions on your
> behalf.
>
> Otherwise, I respectfully submit for your consideration, it is time to
> declare  branch-1 and all 1.x code lines EOL, simply acknowledging what has
> effectively already happened.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk
>