You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Andrew Purtell <ap...@apache.org> on 2022/09/26 22:51:53 UTC
About time for 2.5.1
It has been about a month since 2.5.0 and there are ~42 issues
<https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)>
related to 2.5.1. This week I will be grooming the issue tracker for a RC
next week.If you have any pending work for branch-2.5 that you would like
to get in, please set the fix version accordingly.
--
Best regards,
Andrew
Re: About time for 2.5.1
Posted by Andrew Purtell <ap...@apache.org>.
hbase-thirdparty 4.1.2 is released and all branches are updated to use it.
RC coming today.
On Wed, Oct 5, 2022 at 9:01 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> There are some critical security warnings from dependabot...
>
> I've filed HBASE-27412 for bumping the dependency versions for
> hbase-thirdparty, and we need to make a new hbase-thirdparty first...
>
> Thanks.
>
> Andrew Purtell <ap...@apache.org> 于2022年10月5日周三 03:36写道：
> >
> > Sounds good Duo.
> >
> > On Tue, Oct 4, 2022 at 5:15 AM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
> >
> > > Let's get HBASE-27401 in before 2.5.1. It is just some style fix about
> > > our javadoc and I think it will be done in a few days...
> > >
> > > Thanks.
> > >
> > > Bryan Beaudreault <bb...@hubspot.com.invalid> 于2022年10月4日周二
> > > 01:27写道：
> > > >
> > > > Thanks for your thoughts. I put a PR up a few moments ago for
> > > HBASE-27381.
> > > > I'll start up threads for discussing the other two points.
> > > >
> > > > On Mon, Oct 3, 2022 at 1:05 PM Andrew Purtell <ap...@apache.org>
> > > wrote:
> > > >
> > > > > Thanks Bryan. Responses inline.
> > > > >
> > > > > On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault
> > > > > <bb...@hubspot.com.invalid> wrote:
> > > > >
> > > > > > Thanks Andrew!
> > > > > >
> > > > > > One thing I noticed from 2.5.0 was that a few JIRAs were
> included in
> > > that
> > > > > > release which did not have the proper fixVersions set (so did not
> > > show up
> > > > > > in CHANGES.md
> > > > > <http://CHANGES.md>).
> > > > > I fixed 4 of them before realizing that may not be the way
> > > > > > we should handle it. See [1] for the 4 I fixed (which we could
> > > revert to
> > > > > > 2.5.1 if appropriate), there may be others.
> > > > > >
> > > > >
> > > > > JIRA is supposed to be the canonical source of fix version data,
> so if
> > > > > there have been mistakes, the most important thing to do is update
> JIRA
> > > > > with corrections. If I understand you correctly this is what you
> were
> > > > > doing, and that would be the correct course of action imho. Then,
> if
> > > there
> > > > > was a significant omission from the changelog (something critical
> or
> > > > > blocker, I would say), we could always put out another release
> > > announcement
> > > > > indicating the changelog corrections, or just do that anyway.
> > > > >
> > > > > For the 2.5.1 release I will make a note that the 2.5.0 part of the
> > > > > changelog should be regenerated too to pick up the corrections.
> > > > >
> > > > >
> > > > > > I have filed a few small bugs which I just set the fixVersion to
> > > 2.5.1
> > > > > and
> > > > > > will try to get PRs out for soon, but we could also push them
> out if
> > > > > > needed.
> > > > > >
> > > > > > I also have https://issues.apache.org/jira/browse/HBASE-27381
> > > > > <https://issues.apache.org/jira/browse/HBASE-27381>
> > > > > which would
> > > > > > be helpful to have opinions on since it might be worth fixing for
> > > 2.5.1
> > > > > if
> > > > > > possible. It's a recurrence of a past gnarly bug with some API
> > > > > > compatibility concerns.
> > > > > >
> > > > >
> > > > > +1 for removal. We should get this into the next 2.4 and 2.5
> releases.
> > > I
> > > > > will defend the change.
> > > > >
> > > > > >
> > > > > > A 2.6.0 release this calendar year would be great! We have
> completed
> > > most
> > > > > > of the TLS work at this point. One other thing I was considering
> > > adding
> > > > > to
> > > > > > 2.6.0 was a backport of hbase-backups. There is a PR [2] from
> > > > > Mallikarjun,
> > > > > > we are currently evaluating internally. I think backporting to
> 2.x
> > > will
> > > > > > help get more exposure and contributions, since most people
> aren't
> > > > > running
> > > > > > 3.0-alpha and there's still a backlog of nice-to-haves in the
> "Phase
> > > 4"
> > > > > > jira [3] that have languished a bit. I realize this might even
> > > require a
> > > > > > VOTE thread given the past history? I was only going to bring it
> up
> > > if
> > > > > our
> > > > > > evaluation worked out, but seemed relevant to your 2.6.0
> question.
> > > > > >
> > > > >
> > > > > Let's discuss what release criteria for TLS RPC might look like. We
> > > can set
> > > > > a tentative release date for 2.6.0 for the second week of December,
> > > with RC
> > > > > in the first week, to get things moving. Let's start a new thread
> on
> > > what
> > > > > kind of testing and qualification people would like to see. I have
> some
> > > > > thoughts on the minimum bar I would set as a RM.
> > > > >
> > > > > Regarding the proposed backport of hbase-backups, what I would
> suggest
> > > is
> > > > > raising a DISCUSS thread first. We shouldn't need a VOTE if we can
> get
> > > a
> > > > > consensus that the backport is fine, perhaps after giving the
> feature
> > > the
> > > > > usual qualification of "experimental" when performing a backport of
> > > this
> > > > > nature. An alternative viewpoint would be we should finish and
> polish
> > > the
> > > > > 3.0.0 release to ship backup. Help Duo finish it, get a 3.0.0 out
> that
> > > is
> > > > > not designated alpha. I do want to acknowledge the tradeoff... In
> > > order to
> > > > > make use of a backup feature released in 3.0.0, one would need to
> > > upgrade
> > > > > production to it, which may be a bridge too far; and so any
> > > significant use
> > > > > of it might be delayed, maybe for a long time, but if it were
> released
> > > in a
> > > > > 2.x version it would likely get near term evaluation. Anyway this
> would
> > > > > make a great separate DISCUSS thread :-) .
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > >
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > > > > <
> > >
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > > >
> > > > > > [2] https://github.com/apache/hbase/pull/4770
> > > > > <https://github.com/apache/hbase/pull/4770>
> > > > > > [3] https://issues.apache.org/jira/browse/HBASE-17362
> > > > > <https://issues.apache.org/jira/browse/HBASE-17362>
> > > > > >
> > > > > > On Tue, Sep 27, 2022 at 11:13 AM Andrew Purtell <
> > > > > andrew.purtell@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > We are already flattening and the proposed change adds release
> > > > > artifacts
> > > > > > > for hadoop3 using a new “hadoop3” classifier — at least, that
> is
> > > the
> > > > > > plan,
> > > > > > > let’s see if it works — and so the changes are additive. The
> > > default
> > > > > > build,
> > > > > > > which downstreamers consume as of 2.5.0 and all previous
> releases,
> > > > > > remains
> > > > > > > unchanged with respect to its dependency set. I think this
> means
> > > the
> > > > > > > changes are additive and orthogonal. That said I’d be fine with
> > > waiting
> > > > > > > until 2.6.0 to introduce the hadoop3 variant… in which case I
> would
> > > > > begin
> > > > > > > work on 2.6.0RC0 for anticipated release this calendar year.
> YDYT?
> > > > > > >
> > > > > > > > On Sep 27, 2022, at 7:15 AM, 张铎 <pa...@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > But I think flatten the pom profiles itself is also useful?
> It
> > > does
> > > > > > > > not make sense(and also does not work...) to activate a
> profile
> > > which
> > > > > > > > pulls in jars that are different from the ones we depend at
> the
> > > time
> > > > > > > > when building the hbase artifacts...
> > > > > > > >
> > > > > > > > Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
> > > > > > > >
> > > > > > > >>
> > > > > > > >> Yes -- that's why I brought it up in this discussion. I
> think
> > > that
> > > > > we
> > > > > > > >> should either finish the effort before 2.5.1 or revert it
> from
> > > > > > > >> branch-2.5 until we have a more complete implementation in
> > > place.
> > > > > > > >>
> > > > > > > >>> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <
> > > > > > palomino219@gmail.com>
> > > > > > > wrote:
> > > > > > > >>>
> > > > > > > >>> We already include HBASE-27340 in branch-2.5... So in the
> 2.5.1
> > > > > > > >>> release we will flatten the pom file, if we do not revert
> this
> > > > > > > >>> commit...
> > > > > > > >>>
> > > > > > > >>> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> > > > > > > >>>>
> > > > > > > >>>> I am also concerned about the feature that squashes out
> the
> > > > > profiles
> > > > > > > from
> > > > > > > >>>> our poms. To me, specifying the maven profile at build
> time
> > > is a
> > > > > > part
> > > > > > > of
> > > > > > > >>>> the API contract that we should not break in a patch
> release.
> > > I’d
> > > > > > > like to
> > > > > > > >>>> see that feature integrated into the do-release tooling
> such
> > > that
> > > > > > two
> > > > > > > sets
> > > > > > > >>>> of squished artifacts/maven repos are produced. And of
> course,
> > > > > > > updating the
> > > > > > > >>>> docs to explain how these are consumed.
> > > > > > > >>>>
> > > > > > > >>>> Maybe we need a minor release line where we ship both the
> old
> > > > > style
> > > > > > > and the
> > > > > > > >>>> new style artifacts? We could do that with 2.5…
> > > > > > > >>>>
> > > > > > > >>>> Thanks,
> > > > > > > >>>> Nick
> > > > > > > >>>>
> > > > > > > >>>> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <
> > > > > palomino219@gmail.com>
> > > > > > > wrote:
> > > > > > > >>>>
> > > > > > > >>>>> Thanks Andrew for taking care of this.
> > > > > > > >>>>>
> > > > > > > >>>>> For me there is an issue HBASE-27359, where we can
> publish
> > > > > > different
> > > > > > > >>>>> maven artifacts for hadoop2 and hadoop3, it can solve the
> > > problem
> > > > > > > >>>>> brought up by the phoenix guys. Do you think we should
> > > include
> > > > > this
> > > > > > > in
> > > > > > > >>>>> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is
> too
> > > late
> > > > > > for
> > > > > > > >>>>> 2.5.1, to publish different maven artifacts for hadoop2
> and
> > > > > > hadoop3,
> > > > > > > >>>>> or we still keep 2.5.x as is, and include this in the up
> > > coming
> > > > > > 2.6.x
> > > > > > > >>>>> release line?
> > > > > > > >>>>>
> > > > > > > >>>>> Thanks.
> > > > > > > >>>>>
> > > > > > > >>>>> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二
> 06:52写道：
> > > > > > > >>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>> It has been about a month since 2.5.0 and there are ~42
> > > issues
> > > > > > > >>>>>> <
> > > > > > > >>>>>
> > > > > > >
> > > > > >
> > > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > > > <
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > >
> > > > > > > <
> > > > > >
> > > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > > > <
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > >
> > > > > > >
> > > > > > > >>>>>>
> > > > > > > >>>>>> related to 2.5.1. This week I will be grooming the issue
> > > tracker
> > > > > > > for a RC
> > > > > > > >>>>>> next week.If you have any pending work for branch-2.5
> that
> > > you
> > > > > > > would like
> > > > > > > >>>>>> to get in, please set the fix version accordingly.
> > > > > > > >>>>>>
> > > > > > > >>>>>> --
> > > > > > > >>>>>> Best regards,
> > > > > > > >>>>>> Andrew
> > > > > > > >>>>>
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > > > Unrest, ignorance distilled, nihilistic imbeciles -
> > > > > It's what we’ve earned
> > > > > Welcome, apocalypse, what’s taken you so long?
> > > > > Bring us the fitting end that we’ve been counting on
> > > > > - A23, Welcome, Apocalypse
> > > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Unrest, ignorance distilled, nihilistic imbeciles -
> > It's what we’ve earned
> > Welcome, apocalypse, what’s taken you so long?
> > Bring us the fitting end that we’ve been counting on
> > - A23, Welcome, Apocalypse
>
--
Best regards,
Andrew
Unrest, ignorance distilled, nihilistic imbeciles -
It's what we’ve earned
Welcome, apocalypse, what’s taken you so long?
Bring us the fitting end that we’ve been counting on
- A23, Welcome, Apocalypse
Re: About time for 2.5.1
Posted by Andrew Purtell <ap...@apache.org>.
Unless it is a critical vulnerability we don't need to hold up a release.
The train will leave the station again soon.
For example for HBASE-27412
In FasterXML jackson-databind before 2.13.4, resource exhaustion can occur
> because of a lack of a check in BeanDeserializer._deserializeFromArray to
> prevent use of deeply nested arrays. An application is vulnerable only with
> certain customized choices for deserialization.
This is not a critical security problem for us.
That said, if you are going to run a hbase-thirdparty release right now, we
can certainly wait to consume it before moving forward with 2.4 or 2.5
releasing.
On Wed, Oct 5, 2022 at 9:01 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> There are some critical security warnings from dependabot...
>
> I've filed HBASE-27412 for bumping the dependency versions for
> hbase-thirdparty, and we need to make a new hbase-thirdparty first...
>
> Thanks.
>
> Andrew Purtell <ap...@apache.org> 于2022年10月5日周三 03:36写道：
> >
> > Sounds good Duo.
> >
> > On Tue, Oct 4, 2022 at 5:15 AM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
> >
> > > Let's get HBASE-27401 in before 2.5.1. It is just some style fix about
> > > our javadoc and I think it will be done in a few days...
> > >
> > > Thanks.
> > >
> > > Bryan Beaudreault <bb...@hubspot.com.invalid> 于2022年10月4日周二
> > > 01:27写道：
> > > >
> > > > Thanks for your thoughts. I put a PR up a few moments ago for
> > > HBASE-27381.
> > > > I'll start up threads for discussing the other two points.
> > > >
> > > > On Mon, Oct 3, 2022 at 1:05 PM Andrew Purtell <ap...@apache.org>
> > > wrote:
> > > >
> > > > > Thanks Bryan. Responses inline.
> > > > >
> > > > > On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault
> > > > > <bb...@hubspot.com.invalid> wrote:
> > > > >
> > > > > > Thanks Andrew!
> > > > > >
> > > > > > One thing I noticed from 2.5.0 was that a few JIRAs were
> included in
> > > that
> > > > > > release which did not have the proper fixVersions set (so did not
> > > show up
> > > > > > in CHANGES.md
> > > > > <http://CHANGES.md>).
> > > > > I fixed 4 of them before realizing that may not be the way
> > > > > > we should handle it. See [1] for the 4 I fixed (which we could
> > > revert to
> > > > > > 2.5.1 if appropriate), there may be others.
> > > > > >
> > > > >
> > > > > JIRA is supposed to be the canonical source of fix version data,
> so if
> > > > > there have been mistakes, the most important thing to do is update
> JIRA
> > > > > with corrections. If I understand you correctly this is what you
> were
> > > > > doing, and that would be the correct course of action imho. Then,
> if
> > > there
> > > > > was a significant omission from the changelog (something critical
> or
> > > > > blocker, I would say), we could always put out another release
> > > announcement
> > > > > indicating the changelog corrections, or just do that anyway.
> > > > >
> > > > > For the 2.5.1 release I will make a note that the 2.5.0 part of the
> > > > > changelog should be regenerated too to pick up the corrections.
> > > > >
> > > > >
> > > > > > I have filed a few small bugs which I just set the fixVersion to
> > > 2.5.1
> > > > > and
> > > > > > will try to get PRs out for soon, but we could also push them
> out if
> > > > > > needed.
> > > > > >
> > > > > > I also have https://issues.apache.org/jira/browse/HBASE-27381
> > > > > <https://issues.apache.org/jira/browse/HBASE-27381>
> > > > > which would
> > > > > > be helpful to have opinions on since it might be worth fixing for
> > > 2.5.1
> > > > > if
> > > > > > possible. It's a recurrence of a past gnarly bug with some API
> > > > > > compatibility concerns.
> > > > > >
> > > > >
> > > > > +1 for removal. We should get this into the next 2.4 and 2.5
> releases.
> > > I
> > > > > will defend the change.
> > > > >
> > > > > >
> > > > > > A 2.6.0 release this calendar year would be great! We have
> completed
> > > most
> > > > > > of the TLS work at this point. One other thing I was considering
> > > adding
> > > > > to
> > > > > > 2.6.0 was a backport of hbase-backups. There is a PR [2] from
> > > > > Mallikarjun,
> > > > > > we are currently evaluating internally. I think backporting to
> 2.x
> > > will
> > > > > > help get more exposure and contributions, since most people
> aren't
> > > > > running
> > > > > > 3.0-alpha and there's still a backlog of nice-to-haves in the
> "Phase
> > > 4"
> > > > > > jira [3] that have languished a bit. I realize this might even
> > > require a
> > > > > > VOTE thread given the past history? I was only going to bring it
> up
> > > if
> > > > > our
> > > > > > evaluation worked out, but seemed relevant to your 2.6.0
> question.
> > > > > >
> > > > >
> > > > > Let's discuss what release criteria for TLS RPC might look like. We
> > > can set
> > > > > a tentative release date for 2.6.0 for the second week of December,
> > > with RC
> > > > > in the first week, to get things moving. Let's start a new thread
> on
> > > what
> > > > > kind of testing and qualification people would like to see. I have
> some
> > > > > thoughts on the minimum bar I would set as a RM.
> > > > >
> > > > > Regarding the proposed backport of hbase-backups, what I would
> suggest
> > > is
> > > > > raising a DISCUSS thread first. We shouldn't need a VOTE if we can
> get
> > > a
> > > > > consensus that the backport is fine, perhaps after giving the
> feature
> > > the
> > > > > usual qualification of "experimental" when performing a backport of
> > > this
> > > > > nature. An alternative viewpoint would be we should finish and
> polish
> > > the
> > > > > 3.0.0 release to ship backup. Help Duo finish it, get a 3.0.0 out
> that
> > > is
> > > > > not designated alpha. I do want to acknowledge the tradeoff... In
> > > order to
> > > > > make use of a backup feature released in 3.0.0, one would need to
> > > upgrade
> > > > > production to it, which may be a bridge too far; and so any
> > > significant use
> > > > > of it might be delayed, maybe for a long time, but if it were
> released
> > > in a
> > > > > 2.x version it would likely get near term evaluation. Anyway this
> would
> > > > > make a great separate DISCUSS thread :-) .
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > >
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > > > > <
> > >
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > > >
> > > > > > [2] https://github.com/apache/hbase/pull/4770
> > > > > <https://github.com/apache/hbase/pull/4770>
> > > > > > [3] https://issues.apache.org/jira/browse/HBASE-17362
> > > > > <https://issues.apache.org/jira/browse/HBASE-17362>
> > > > > >
> > > > > > On Tue, Sep 27, 2022 at 11:13 AM Andrew Purtell <
> > > > > andrew.purtell@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > We are already flattening and the proposed change adds release
> > > > > artifacts
> > > > > > > for hadoop3 using a new “hadoop3” classifier — at least, that
> is
> > > the
> > > > > > plan,
> > > > > > > let’s see if it works — and so the changes are additive. The
> > > default
> > > > > > build,
> > > > > > > which downstreamers consume as of 2.5.0 and all previous
> releases,
> > > > > > remains
> > > > > > > unchanged with respect to its dependency set. I think this
> means
> > > the
> > > > > > > changes are additive and orthogonal. That said I’d be fine with
> > > waiting
> > > > > > > until 2.6.0 to introduce the hadoop3 variant… in which case I
> would
> > > > > begin
> > > > > > > work on 2.6.0RC0 for anticipated release this calendar year.
> YDYT?
> > > > > > >
> > > > > > > > On Sep 27, 2022, at 7:15 AM, 张铎 <pa...@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > But I think flatten the pom profiles itself is also useful?
> It
> > > does
> > > > > > > > not make sense(and also does not work...) to activate a
> profile
> > > which
> > > > > > > > pulls in jars that are different from the ones we depend at
> the
> > > time
> > > > > > > > when building the hbase artifacts...
> > > > > > > >
> > > > > > > > Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
> > > > > > > >
> > > > > > > >>
> > > > > > > >> Yes -- that's why I brought it up in this discussion. I
> think
> > > that
> > > > > we
> > > > > > > >> should either finish the effort before 2.5.1 or revert it
> from
> > > > > > > >> branch-2.5 until we have a more complete implementation in
> > > place.
> > > > > > > >>
> > > > > > > >>> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <
> > > > > > palomino219@gmail.com>
> > > > > > > wrote:
> > > > > > > >>>
> > > > > > > >>> We already include HBASE-27340 in branch-2.5... So in the
> 2.5.1
> > > > > > > >>> release we will flatten the pom file, if we do not revert
> this
> > > > > > > >>> commit...
> > > > > > > >>>
> > > > > > > >>> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> > > > > > > >>>>
> > > > > > > >>>> I am also concerned about the feature that squashes out
> the
> > > > > profiles
> > > > > > > from
> > > > > > > >>>> our poms. To me, specifying the maven profile at build
> time
> > > is a
> > > > > > part
> > > > > > > of
> > > > > > > >>>> the API contract that we should not break in a patch
> release.
> > > I’d
> > > > > > > like to
> > > > > > > >>>> see that feature integrated into the do-release tooling
> such
> > > that
> > > > > > two
> > > > > > > sets
> > > > > > > >>>> of squished artifacts/maven repos are produced. And of
> course,
> > > > > > > updating the
> > > > > > > >>>> docs to explain how these are consumed.
> > > > > > > >>>>
> > > > > > > >>>> Maybe we need a minor release line where we ship both the
> old
> > > > > style
> > > > > > > and the
> > > > > > > >>>> new style artifacts? We could do that with 2.5…
> > > > > > > >>>>
> > > > > > > >>>> Thanks,
> > > > > > > >>>> Nick
> > > > > > > >>>>
> > > > > > > >>>> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <
> > > > > palomino219@gmail.com>
> > > > > > > wrote:
> > > > > > > >>>>
> > > > > > > >>>>> Thanks Andrew for taking care of this.
> > > > > > > >>>>>
> > > > > > > >>>>> For me there is an issue HBASE-27359, where we can
> publish
> > > > > > different
> > > > > > > >>>>> maven artifacts for hadoop2 and hadoop3, it can solve the
> > > problem
> > > > > > > >>>>> brought up by the phoenix guys. Do you think we should
> > > include
> > > > > this
> > > > > > > in
> > > > > > > >>>>> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is
> too
> > > late
> > > > > > for
> > > > > > > >>>>> 2.5.1, to publish different maven artifacts for hadoop2
> and
> > > > > > hadoop3,
> > > > > > > >>>>> or we still keep 2.5.x as is, and include this in the up
> > > coming
> > > > > > 2.6.x
> > > > > > > >>>>> release line?
> > > > > > > >>>>>
> > > > > > > >>>>> Thanks.
> > > > > > > >>>>>
> > > > > > > >>>>> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二
> 06:52写道：
> > > > > > > >>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>> It has been about a month since 2.5.0 and there are ~42
> > > issues
> > > > > > > >>>>>> <
> > > > > > > >>>>>
> > > > > > >
> > > > > >
> > > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > > > <
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > >
> > > > > > > <
> > > > > >
> > > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > > > <
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > >
> > > > > > >
> > > > > > > >>>>>>
> > > > > > > >>>>>> related to 2.5.1. This week I will be grooming the issue
> > > tracker
> > > > > > > for a RC
> > > > > > > >>>>>> next week.If you have any pending work for branch-2.5
> that
> > > you
> > > > > > > would like
> > > > > > > >>>>>> to get in, please set the fix version accordingly.
> > > > > > > >>>>>>
> > > > > > > >>>>>> --
> > > > > > > >>>>>> Best regards,
> > > > > > > >>>>>> Andrew
> > > > > > > >>>>>
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > > > Unrest, ignorance distilled, nihilistic imbeciles -
> > > > > It's what we’ve earned
> > > > > Welcome, apocalypse, what’s taken you so long?
> > > > > Bring us the fitting end that we’ve been counting on
> > > > > - A23, Welcome, Apocalypse
> > > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Unrest, ignorance distilled, nihilistic imbeciles -
> > It's what we’ve earned
> > Welcome, apocalypse, what’s taken you so long?
> > Bring us the fitting end that we’ve been counting on
> > - A23, Welcome, Apocalypse
>
--
Best regards,
Andrew
Unrest, ignorance distilled, nihilistic imbeciles -
It's what we’ve earned
Welcome, apocalypse, what’s taken you so long?
Bring us the fitting end that we’ve been counting on
- A23, Welcome, Apocalypse
Re: About time for 2.5.1
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
There are some critical security warnings from dependabot...
I've filed HBASE-27412 for bumping the dependency versions for
hbase-thirdparty, and we need to make a new hbase-thirdparty first...
Thanks.
Andrew Purtell <ap...@apache.org> 于2022年10月5日周三 03:36写道：
>
> Sounds good Duo.
>
> On Tue, Oct 4, 2022 at 5:15 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>
> > Let's get HBASE-27401 in before 2.5.1. It is just some style fix about
> > our javadoc and I think it will be done in a few days...
> >
> > Thanks.
> >
> > Bryan Beaudreault <bb...@hubspot.com.invalid> 于2022年10月4日周二
> > 01:27写道：
> > >
> > > Thanks for your thoughts. I put a PR up a few moments ago for
> > HBASE-27381.
> > > I'll start up threads for discussing the other two points.
> > >
> > > On Mon, Oct 3, 2022 at 1:05 PM Andrew Purtell <ap...@apache.org>
> > wrote:
> > >
> > > > Thanks Bryan. Responses inline.
> > > >
> > > > On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault
> > > > <bb...@hubspot.com.invalid> wrote:
> > > >
> > > > > Thanks Andrew!
> > > > >
> > > > > One thing I noticed from 2.5.0 was that a few JIRAs were included in
> > that
> > > > > release which did not have the proper fixVersions set (so did not
> > show up
> > > > > in CHANGES.md
> > > > <http://CHANGES.md>).
> > > > I fixed 4 of them before realizing that may not be the way
> > > > > we should handle it. See [1] for the 4 I fixed (which we could
> > revert to
> > > > > 2.5.1 if appropriate), there may be others.
> > > > >
> > > >
> > > > JIRA is supposed to be the canonical source of fix version data, so if
> > > > there have been mistakes, the most important thing to do is update JIRA
> > > > with corrections. If I understand you correctly this is what you were
> > > > doing, and that would be the correct course of action imho. Then, if
> > there
> > > > was a significant omission from the changelog (something critical or
> > > > blocker, I would say), we could always put out another release
> > announcement
> > > > indicating the changelog corrections, or just do that anyway.
> > > >
> > > > For the 2.5.1 release I will make a note that the 2.5.0 part of the
> > > > changelog should be regenerated too to pick up the corrections.
> > > >
> > > >
> > > > > I have filed a few small bugs which I just set the fixVersion to
> > 2.5.1
> > > > and
> > > > > will try to get PRs out for soon, but we could also push them out if
> > > > > needed.
> > > > >
> > > > > I also have https://issues.apache.org/jira/browse/HBASE-27381
> > > > <https://issues.apache.org/jira/browse/HBASE-27381>
> > > > which would
> > > > > be helpful to have opinions on since it might be worth fixing for
> > 2.5.1
> > > > if
> > > > > possible. It's a recurrence of a past gnarly bug with some API
> > > > > compatibility concerns.
> > > > >
> > > >
> > > > +1 for removal. We should get this into the next 2.4 and 2.5 releases.
> > I
> > > > will defend the change.
> > > >
> > > > >
> > > > > A 2.6.0 release this calendar year would be great! We have completed
> > most
> > > > > of the TLS work at this point. One other thing I was considering
> > adding
> > > > to
> > > > > 2.6.0 was a backport of hbase-backups. There is a PR [2] from
> > > > Mallikarjun,
> > > > > we are currently evaluating internally. I think backporting to 2.x
> > will
> > > > > help get more exposure and contributions, since most people aren't
> > > > running
> > > > > 3.0-alpha and there's still a backlog of nice-to-haves in the "Phase
> > 4"
> > > > > jira [3] that have languished a bit. I realize this might even
> > require a
> > > > > VOTE thread given the past history? I was only going to bring it up
> > if
> > > > our
> > > > > evaluation worked out, but seemed relevant to your 2.6.0 question.
> > > > >
> > > >
> > > > Let's discuss what release criteria for TLS RPC might look like. We
> > can set
> > > > a tentative release date for 2.6.0 for the second week of December,
> > with RC
> > > > in the first week, to get things moving. Let's start a new thread on
> > what
> > > > kind of testing and qualification people would like to see. I have some
> > > > thoughts on the minimum bar I would set as a RM.
> > > >
> > > > Regarding the proposed backport of hbase-backups, what I would suggest
> > is
> > > > raising a DISCUSS thread first. We shouldn't need a VOTE if we can get
> > a
> > > > consensus that the backport is fine, perhaps after giving the feature
> > the
> > > > usual qualification of "experimental" when performing a backport of
> > this
> > > > nature. An alternative viewpoint would be we should finish and polish
> > the
> > > > 3.0.0 release to ship backup. Help Duo finish it, get a 3.0.0 out that
> > is
> > > > not designated alpha. I do want to acknowledge the tradeoff... In
> > order to
> > > > make use of a backup feature released in 3.0.0, one would need to
> > upgrade
> > > > production to it, which may be a bridge too far; and so any
> > significant use
> > > > of it might be delayed, maybe for a long time, but if it were released
> > in a
> > > > 2.x version it would likely get near term evaluation. Anyway this would
> > > > make a great separate DISCUSS thread :-) .
> > > >
> > > >
> > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > > > <
> > https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > >
> > > > > [2] https://github.com/apache/hbase/pull/4770
> > > > <https://github.com/apache/hbase/pull/4770>
> > > > > [3] https://issues.apache.org/jira/browse/HBASE-17362
> > > > <https://issues.apache.org/jira/browse/HBASE-17362>
> > > > >
> > > > > On Tue, Sep 27, 2022 at 11:13 AM Andrew Purtell <
> > > > andrew.purtell@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > We are already flattening and the proposed change adds release
> > > > artifacts
> > > > > > for hadoop3 using a new “hadoop3” classifier — at least, that is
> > the
> > > > > plan,
> > > > > > let’s see if it works — and so the changes are additive. The
> > default
> > > > > build,
> > > > > > which downstreamers consume as of 2.5.0 and all previous releases,
> > > > > remains
> > > > > > unchanged with respect to its dependency set. I think this means
> > the
> > > > > > changes are additive and orthogonal. That said I’d be fine with
> > waiting
> > > > > > until 2.6.0 to introduce the hadoop3 variant… in which case I would
> > > > begin
> > > > > > work on 2.6.0RC0 for anticipated release this calendar year. YDYT?
> > > > > >
> > > > > > > On Sep 27, 2022, at 7:15 AM, 张铎 <pa...@gmail.com> wrote:
> > > > > > >
> > > > > > > But I think flatten the pom profiles itself is also useful? It
> > does
> > > > > > > not make sense(and also does not work...) to activate a profile
> > which
> > > > > > > pulls in jars that are different from the ones we depend at the
> > time
> > > > > > > when building the hbase artifacts...
> > > > > > >
> > > > > > > Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
> > > > > > >
> > > > > > >>
> > > > > > >> Yes -- that's why I brought it up in this discussion. I think
> > that
> > > > we
> > > > > > >> should either finish the effort before 2.5.1 or revert it from
> > > > > > >> branch-2.5 until we have a more complete implementation in
> > place.
> > > > > > >>
> > > > > > >>> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <
> > > > > palomino219@gmail.com>
> > > > > > wrote:
> > > > > > >>>
> > > > > > >>> We already include HBASE-27340 in branch-2.5... So in the 2.5.1
> > > > > > >>> release we will flatten the pom file, if we do not revert this
> > > > > > >>> commit...
> > > > > > >>>
> > > > > > >>> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> > > > > > >>>>
> > > > > > >>>> I am also concerned about the feature that squashes out the
> > > > profiles
> > > > > > from
> > > > > > >>>> our poms. To me, specifying the maven profile at build time
> > is a
> > > > > part
> > > > > > of
> > > > > > >>>> the API contract that we should not break in a patch release.
> > I’d
> > > > > > like to
> > > > > > >>>> see that feature integrated into the do-release tooling such
> > that
> > > > > two
> > > > > > sets
> > > > > > >>>> of squished artifacts/maven repos are produced. And of course,
> > > > > > updating the
> > > > > > >>>> docs to explain how these are consumed.
> > > > > > >>>>
> > > > > > >>>> Maybe we need a minor release line where we ship both the old
> > > > style
> > > > > > and the
> > > > > > >>>> new style artifacts? We could do that with 2.5…
> > > > > > >>>>
> > > > > > >>>> Thanks,
> > > > > > >>>> Nick
> > > > > > >>>>
> > > > > > >>>> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <
> > > > palomino219@gmail.com>
> > > > > > wrote:
> > > > > > >>>>
> > > > > > >>>>> Thanks Andrew for taking care of this.
> > > > > > >>>>>
> > > > > > >>>>> For me there is an issue HBASE-27359, where we can publish
> > > > > different
> > > > > > >>>>> maven artifacts for hadoop2 and hadoop3, it can solve the
> > problem
> > > > > > >>>>> brought up by the phoenix guys. Do you think we should
> > include
> > > > this
> > > > > > in
> > > > > > >>>>> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too
> > late
> > > > > for
> > > > > > >>>>> 2.5.1, to publish different maven artifacts for hadoop2 and
> > > > > hadoop3,
> > > > > > >>>>> or we still keep 2.5.x as is, and include this in the up
> > coming
> > > > > 2.6.x
> > > > > > >>>>> release line?
> > > > > > >>>>>
> > > > > > >>>>> Thanks.
> > > > > > >>>>>
> > > > > > >>>>> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
> > > > > > >>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> It has been about a month since 2.5.0 and there are ~42
> > issues
> > > > > > >>>>>> <
> > > > > > >>>>>
> > > > > >
> > > > >
> > > >
> > https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > > <
> > https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > >
> > > > > > <
> > > > >
> > > >
> > https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > > <
> > https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > >
> > > > > >
> > > > > > >>>>>>
> > > > > > >>>>>> related to 2.5.1. This week I will be grooming the issue
> > tracker
> > > > > > for a RC
> > > > > > >>>>>> next week.If you have any pending work for branch-2.5 that
> > you
> > > > > > would like
> > > > > > >>>>>> to get in, please set the fix version accordingly.
> > > > > > >>>>>>
> > > > > > >>>>>> --
> > > > > > >>>>>> Best regards,
> > > > > > >>>>>> Andrew
> > > > > > >>>>>
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Unrest, ignorance distilled, nihilistic imbeciles -
> > > > It's what we’ve earned
> > > > Welcome, apocalypse, what’s taken you so long?
> > > > Bring us the fitting end that we’ve been counting on
> > > > - A23, Welcome, Apocalypse
> > > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Unrest, ignorance distilled, nihilistic imbeciles -
> It's what we’ve earned
> Welcome, apocalypse, what’s taken you so long?
> Bring us the fitting end that we’ve been counting on
> - A23, Welcome, Apocalypse
Re: About time for 2.5.1
Posted by Andrew Purtell <ap...@apache.org>.
Sounds good Duo.
On Tue, Oct 4, 2022 at 5:15 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> Let's get HBASE-27401 in before 2.5.1. It is just some style fix about
> our javadoc and I think it will be done in a few days...
>
> Thanks.
>
> Bryan Beaudreault <bb...@hubspot.com.invalid> 于2022年10月4日周二
> 01:27写道：
> >
> > Thanks for your thoughts. I put a PR up a few moments ago for
> HBASE-27381.
> > I'll start up threads for discussing the other two points.
> >
> > On Mon, Oct 3, 2022 at 1:05 PM Andrew Purtell <ap...@apache.org>
> wrote:
> >
> > > Thanks Bryan. Responses inline.
> > >
> > > On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault
> > > <bb...@hubspot.com.invalid> wrote:
> > >
> > > > Thanks Andrew!
> > > >
> > > > One thing I noticed from 2.5.0 was that a few JIRAs were included in
> that
> > > > release which did not have the proper fixVersions set (so did not
> show up
> > > > in CHANGES.md
> > > <http://CHANGES.md>).
> > > I fixed 4 of them before realizing that may not be the way
> > > > we should handle it. See [1] for the 4 I fixed (which we could
> revert to
> > > > 2.5.1 if appropriate), there may be others.
> > > >
> > >
> > > JIRA is supposed to be the canonical source of fix version data, so if
> > > there have been mistakes, the most important thing to do is update JIRA
> > > with corrections. If I understand you correctly this is what you were
> > > doing, and that would be the correct course of action imho. Then, if
> there
> > > was a significant omission from the changelog (something critical or
> > > blocker, I would say), we could always put out another release
> announcement
> > > indicating the changelog corrections, or just do that anyway.
> > >
> > > For the 2.5.1 release I will make a note that the 2.5.0 part of the
> > > changelog should be regenerated too to pick up the corrections.
> > >
> > >
> > > > I have filed a few small bugs which I just set the fixVersion to
> 2.5.1
> > > and
> > > > will try to get PRs out for soon, but we could also push them out if
> > > > needed.
> > > >
> > > > I also have https://issues.apache.org/jira/browse/HBASE-27381
> > > <https://issues.apache.org/jira/browse/HBASE-27381>
> > > which would
> > > > be helpful to have opinions on since it might be worth fixing for
> 2.5.1
> > > if
> > > > possible. It's a recurrence of a past gnarly bug with some API
> > > > compatibility concerns.
> > > >
> > >
> > > +1 for removal. We should get this into the next 2.4 and 2.5 releases.
> I
> > > will defend the change.
> > >
> > > >
> > > > A 2.6.0 release this calendar year would be great! We have completed
> most
> > > > of the TLS work at this point. One other thing I was considering
> adding
> > > to
> > > > 2.6.0 was a backport of hbase-backups. There is a PR [2] from
> > > Mallikarjun,
> > > > we are currently evaluating internally. I think backporting to 2.x
> will
> > > > help get more exposure and contributions, since most people aren't
> > > running
> > > > 3.0-alpha and there's still a backlog of nice-to-haves in the "Phase
> 4"
> > > > jira [3] that have languished a bit. I realize this might even
> require a
> > > > VOTE thread given the past history? I was only going to bring it up
> if
> > > our
> > > > evaluation worked out, but seemed relevant to your 2.6.0 question.
> > > >
> > >
> > > Let's discuss what release criteria for TLS RPC might look like. We
> can set
> > > a tentative release date for 2.6.0 for the second week of December,
> with RC
> > > in the first week, to get things moving. Let's start a new thread on
> what
> > > kind of testing and qualification people would like to see. I have some
> > > thoughts on the minimum bar I would set as a RM.
> > >
> > > Regarding the proposed backport of hbase-backups, what I would suggest
> is
> > > raising a DISCUSS thread first. We shouldn't need a VOTE if we can get
> a
> > > consensus that the backport is fine, perhaps after giving the feature
> the
> > > usual qualification of "experimental" when performing a backport of
> this
> > > nature. An alternative viewpoint would be we should finish and polish
> the
> > > 3.0.0 release to ship backup. Help Duo finish it, get a 3.0.0 out that
> is
> > > not designated alpha. I do want to acknowledge the tradeoff... In
> order to
> > > make use of a backup feature released in 3.0.0, one would need to
> upgrade
> > > production to it, which may be a bridge too far; and so any
> significant use
> > > of it might be delayed, maybe for a long time, but if it were released
> in a
> > > 2.x version it would likely get near term evaluation. Anyway this would
> > > make a great separate DISCUSS thread :-) .
> > >
> > >
> > >
> > > >
> > > > [1]
> > > >
> > > >
> > >
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > > <
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> >
> > > > [2] https://github.com/apache/hbase/pull/4770
> > > <https://github.com/apache/hbase/pull/4770>
> > > > [3] https://issues.apache.org/jira/browse/HBASE-17362
> > > <https://issues.apache.org/jira/browse/HBASE-17362>
> > > >
> > > > On Tue, Sep 27, 2022 at 11:13 AM Andrew Purtell <
> > > andrew.purtell@gmail.com>
> > > > wrote:
> > > >
> > > > > We are already flattening and the proposed change adds release
> > > artifacts
> > > > > for hadoop3 using a new “hadoop3” classifier — at least, that is
> the
> > > > plan,
> > > > > let’s see if it works — and so the changes are additive. The
> default
> > > > build,
> > > > > which downstreamers consume as of 2.5.0 and all previous releases,
> > > > remains
> > > > > unchanged with respect to its dependency set. I think this means
> the
> > > > > changes are additive and orthogonal. That said I’d be fine with
> waiting
> > > > > until 2.6.0 to introduce the hadoop3 variant… in which case I would
> > > begin
> > > > > work on 2.6.0RC0 for anticipated release this calendar year. YDYT?
> > > > >
> > > > > > On Sep 27, 2022, at 7:15 AM, 张铎 <pa...@gmail.com> wrote:
> > > > > >
> > > > > > But I think flatten the pom profiles itself is also useful? It
> does
> > > > > > not make sense(and also does not work...) to activate a profile
> which
> > > > > > pulls in jars that are different from the ones we depend at the
> time
> > > > > > when building the hbase artifacts...
> > > > > >
> > > > > > Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
> > > > > >
> > > > > >>
> > > > > >> Yes -- that's why I brought it up in this discussion. I think
> that
> > > we
> > > > > >> should either finish the effort before 2.5.1 or revert it from
> > > > > >> branch-2.5 until we have a more complete implementation in
> place.
> > > > > >>
> > > > > >>> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <
> > > > palomino219@gmail.com>
> > > > > wrote:
> > > > > >>>
> > > > > >>> We already include HBASE-27340 in branch-2.5... So in the 2.5.1
> > > > > >>> release we will flatten the pom file, if we do not revert this
> > > > > >>> commit...
> > > > > >>>
> > > > > >>> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> > > > > >>>>
> > > > > >>>> I am also concerned about the feature that squashes out the
> > > profiles
> > > > > from
> > > > > >>>> our poms. To me, specifying the maven profile at build time
> is a
> > > > part
> > > > > of
> > > > > >>>> the API contract that we should not break in a patch release.
> I’d
> > > > > like to
> > > > > >>>> see that feature integrated into the do-release tooling such
> that
> > > > two
> > > > > sets
> > > > > >>>> of squished artifacts/maven repos are produced. And of course,
> > > > > updating the
> > > > > >>>> docs to explain how these are consumed.
> > > > > >>>>
> > > > > >>>> Maybe we need a minor release line where we ship both the old
> > > style
> > > > > and the
> > > > > >>>> new style artifacts? We could do that with 2.5…
> > > > > >>>>
> > > > > >>>> Thanks,
> > > > > >>>> Nick
> > > > > >>>>
> > > > > >>>> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <
> > > palomino219@gmail.com>
> > > > > wrote:
> > > > > >>>>
> > > > > >>>>> Thanks Andrew for taking care of this.
> > > > > >>>>>
> > > > > >>>>> For me there is an issue HBASE-27359, where we can publish
> > > > different
> > > > > >>>>> maven artifacts for hadoop2 and hadoop3, it can solve the
> problem
> > > > > >>>>> brought up by the phoenix guys. Do you think we should
> include
> > > this
> > > > > in
> > > > > >>>>> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too
> late
> > > > for
> > > > > >>>>> 2.5.1, to publish different maven artifacts for hadoop2 and
> > > > hadoop3,
> > > > > >>>>> or we still keep 2.5.x as is, and include this in the up
> coming
> > > > 2.6.x
> > > > > >>>>> release line?
> > > > > >>>>>
> > > > > >>>>> Thanks.
> > > > > >>>>>
> > > > > >>>>> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
> > > > > >>>>>
> > > > > >>>>>>
> > > > > >>>>>> It has been about a month since 2.5.0 and there are ~42
> issues
> > > > > >>>>>> <
> > > > > >>>>>
> > > > >
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > <
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> >
> > > > > <
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > <
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> >
> > > > >
> > > > > >>>>>>
> > > > > >>>>>> related to 2.5.1. This week I will be grooming the issue
> tracker
> > > > > for a RC
> > > > > >>>>>> next week.If you have any pending work for branch-2.5 that
> you
> > > > > would like
> > > > > >>>>>> to get in, please set the fix version accordingly.
> > > > > >>>>>>
> > > > > >>>>>> --
> > > > > >>>>>> Best regards,
> > > > > >>>>>> Andrew
> > > > > >>>>>
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Unrest, ignorance distilled, nihilistic imbeciles -
> > > It's what we’ve earned
> > > Welcome, apocalypse, what’s taken you so long?
> > > Bring us the fitting end that we’ve been counting on
> > > - A23, Welcome, Apocalypse
> > >
>
--
Best regards,
Andrew
Unrest, ignorance distilled, nihilistic imbeciles -
It's what we’ve earned
Welcome, apocalypse, what’s taken you so long?
Bring us the fitting end that we’ve been counting on
- A23, Welcome, Apocalypse
Re: About time for 2.5.1
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
Let's get HBASE-27401 in before 2.5.1. It is just some style fix about
our javadoc and I think it will be done in a few days...
Thanks.
Bryan Beaudreault <bb...@hubspot.com.invalid> 于2022年10月4日周二 01:27写道：
>
> Thanks for your thoughts. I put a PR up a few moments ago for HBASE-27381.
> I'll start up threads for discussing the other two points.
>
> On Mon, Oct 3, 2022 at 1:05 PM Andrew Purtell <ap...@apache.org> wrote:
>
> > Thanks Bryan. Responses inline.
> >
> > On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault
> > <bb...@hubspot.com.invalid> wrote:
> >
> > > Thanks Andrew!
> > >
> > > One thing I noticed from 2.5.0 was that a few JIRAs were included in that
> > > release which did not have the proper fixVersions set (so did not show up
> > > in CHANGES.md
> > <http://CHANGES.md>).
> > I fixed 4 of them before realizing that may not be the way
> > > we should handle it. See [1] for the 4 I fixed (which we could revert to
> > > 2.5.1 if appropriate), there may be others.
> > >
> >
> > JIRA is supposed to be the canonical source of fix version data, so if
> > there have been mistakes, the most important thing to do is update JIRA
> > with corrections. If I understand you correctly this is what you were
> > doing, and that would be the correct course of action imho. Then, if there
> > was a significant omission from the changelog (something critical or
> > blocker, I would say), we could always put out another release announcement
> > indicating the changelog corrections, or just do that anyway.
> >
> > For the 2.5.1 release I will make a note that the 2.5.0 part of the
> > changelog should be regenerated too to pick up the corrections.
> >
> >
> > > I have filed a few small bugs which I just set the fixVersion to 2.5.1
> > and
> > > will try to get PRs out for soon, but we could also push them out if
> > > needed.
> > >
> > > I also have https://issues.apache.org/jira/browse/HBASE-27381
> > <https://issues.apache.org/jira/browse/HBASE-27381>
> > which would
> > > be helpful to have opinions on since it might be worth fixing for 2.5.1
> > if
> > > possible. It's a recurrence of a past gnarly bug with some API
> > > compatibility concerns.
> > >
> >
> > +1 for removal. We should get this into the next 2.4 and 2.5 releases. I
> > will defend the change.
> >
> > >
> > > A 2.6.0 release this calendar year would be great! We have completed most
> > > of the TLS work at this point. One other thing I was considering adding
> > to
> > > 2.6.0 was a backport of hbase-backups. There is a PR [2] from
> > Mallikarjun,
> > > we are currently evaluating internally. I think backporting to 2.x will
> > > help get more exposure and contributions, since most people aren't
> > running
> > > 3.0-alpha and there's still a backlog of nice-to-haves in the "Phase 4"
> > > jira [3] that have languished a bit. I realize this might even require a
> > > VOTE thread given the past history? I was only going to bring it up if
> > our
> > > evaluation worked out, but seemed relevant to your 2.6.0 question.
> > >
> >
> > Let's discuss what release criteria for TLS RPC might look like. We can set
> > a tentative release date for 2.6.0 for the second week of December, with RC
> > in the first week, to get things moving. Let's start a new thread on what
> > kind of testing and qualification people would like to see. I have some
> > thoughts on the minimum bar I would set as a RM.
> >
> > Regarding the proposed backport of hbase-backups, what I would suggest is
> > raising a DISCUSS thread first. We shouldn't need a VOTE if we can get a
> > consensus that the backport is fine, perhaps after giving the feature the
> > usual qualification of "experimental" when performing a backport of this
> > nature. An alternative viewpoint would be we should finish and polish the
> > 3.0.0 release to ship backup. Help Duo finish it, get a 3.0.0 out that is
> > not designated alpha. I do want to acknowledge the tradeoff... In order to
> > make use of a backup feature released in 3.0.0, one would need to upgrade
> > production to it, which may be a bridge too far; and so any significant use
> > of it might be delayed, maybe for a long time, but if it were released in a
> > 2.x version it would likely get near term evaluation. Anyway this would
> > make a great separate DISCUSS thread :-) .
> >
> >
> >
> > >
> > > [1]
> > >
> > >
> > https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> > <https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22>
> > > [2] https://github.com/apache/hbase/pull/4770
> > <https://github.com/apache/hbase/pull/4770>
> > > [3] https://issues.apache.org/jira/browse/HBASE-17362
> > <https://issues.apache.org/jira/browse/HBASE-17362>
> > >
> > > On Tue, Sep 27, 2022 at 11:13 AM Andrew Purtell <
> > andrew.purtell@gmail.com>
> > > wrote:
> > >
> > > > We are already flattening and the proposed change adds release
> > artifacts
> > > > for hadoop3 using a new “hadoop3” classifier — at least, that is the
> > > plan,
> > > > let’s see if it works — and so the changes are additive. The default
> > > build,
> > > > which downstreamers consume as of 2.5.0 and all previous releases,
> > > remains
> > > > unchanged with respect to its dependency set. I think this means the
> > > > changes are additive and orthogonal. That said I’d be fine with waiting
> > > > until 2.6.0 to introduce the hadoop3 variant… in which case I would
> > begin
> > > > work on 2.6.0RC0 for anticipated release this calendar year. YDYT?
> > > >
> > > > > On Sep 27, 2022, at 7:15 AM, 张铎 <pa...@gmail.com> wrote:
> > > > >
> > > > > But I think flatten the pom profiles itself is also useful? It does
> > > > > not make sense(and also does not work...) to activate a profile which
> > > > > pulls in jars that are different from the ones we depend at the time
> > > > > when building the hbase artifacts...
> > > > >
> > > > > Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
> > > > >
> > > > >>
> > > > >> Yes -- that's why I brought it up in this discussion. I think that
> > we
> > > > >> should either finish the effort before 2.5.1 or revert it from
> > > > >> branch-2.5 until we have a more complete implementation in place.
> > > > >>
> > > > >>> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <
> > > palomino219@gmail.com>
> > > > wrote:
> > > > >>>
> > > > >>> We already include HBASE-27340 in branch-2.5... So in the 2.5.1
> > > > >>> release we will flatten the pom file, if we do not revert this
> > > > >>> commit...
> > > > >>>
> > > > >>> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> > > > >>>>
> > > > >>>> I am also concerned about the feature that squashes out the
> > profiles
> > > > from
> > > > >>>> our poms. To me, specifying the maven profile at build time is a
> > > part
> > > > of
> > > > >>>> the API contract that we should not break in a patch release. I’d
> > > > like to
> > > > >>>> see that feature integrated into the do-release tooling such that
> > > two
> > > > sets
> > > > >>>> of squished artifacts/maven repos are produced. And of course,
> > > > updating the
> > > > >>>> docs to explain how these are consumed.
> > > > >>>>
> > > > >>>> Maybe we need a minor release line where we ship both the old
> > style
> > > > and the
> > > > >>>> new style artifacts? We could do that with 2.5…
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>> Nick
> > > > >>>>
> > > > >>>> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <
> > palomino219@gmail.com>
> > > > wrote:
> > > > >>>>
> > > > >>>>> Thanks Andrew for taking care of this.
> > > > >>>>>
> > > > >>>>> For me there is an issue HBASE-27359, where we can publish
> > > different
> > > > >>>>> maven artifacts for hadoop2 and hadoop3, it can solve the problem
> > > > >>>>> brought up by the phoenix guys. Do you think we should include
> > this
> > > > in
> > > > >>>>> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late
> > > for
> > > > >>>>> 2.5.1, to publish different maven artifacts for hadoop2 and
> > > hadoop3,
> > > > >>>>> or we still keep 2.5.x as is, and include this in the up coming
> > > 2.6.x
> > > > >>>>> release line?
> > > > >>>>>
> > > > >>>>> Thanks.
> > > > >>>>>
> > > > >>>>> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
> > > > >>>>>
> > > > >>>>>>
> > > > >>>>>> It has been about a month since 2.5.0 and there are ~42 issues
> > > > >>>>>> <
> > > > >>>>>
> > > >
> > >
> > https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > <https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)>
> > > > <
> > >
> > https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > <https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)>
> > > >
> > > > >>>>>>
> > > > >>>>>> related to 2.5.1. This week I will be grooming the issue tracker
> > > > for a RC
> > > > >>>>>> next week.If you have any pending work for branch-2.5 that you
> > > > would like
> > > > >>>>>> to get in, please set the fix version accordingly.
> > > > >>>>>>
> > > > >>>>>> --
> > > > >>>>>> Best regards,
> > > > >>>>>> Andrew
> > > > >>>>>
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Unrest, ignorance distilled, nihilistic imbeciles -
> > It's what we’ve earned
> > Welcome, apocalypse, what’s taken you so long?
> > Bring us the fitting end that we’ve been counting on
> > - A23, Welcome, Apocalypse
> >
Re: About time for 2.5.1
Posted by Bryan Beaudreault <bb...@hubspot.com.INVALID>.
Thanks for your thoughts. I put a PR up a few moments ago for HBASE-27381.
I'll start up threads for discussing the other two points.
On Mon, Oct 3, 2022 at 1:05 PM Andrew Purtell <ap...@apache.org> wrote:
> Thanks Bryan. Responses inline.
>
> On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault
> <bb...@hubspot.com.invalid> wrote:
>
> > Thanks Andrew!
> >
> > One thing I noticed from 2.5.0 was that a few JIRAs were included in that
> > release which did not have the proper fixVersions set (so did not show up
> > in CHANGES.md
> <http://CHANGES.md>).
> I fixed 4 of them before realizing that may not be the way
> > we should handle it. See [1] for the 4 I fixed (which we could revert to
> > 2.5.1 if appropriate), there may be others.
> >
>
> JIRA is supposed to be the canonical source of fix version data, so if
> there have been mistakes, the most important thing to do is update JIRA
> with corrections. If I understand you correctly this is what you were
> doing, and that would be the correct course of action imho. Then, if there
> was a significant omission from the changelog (something critical or
> blocker, I would say), we could always put out another release announcement
> indicating the changelog corrections, or just do that anyway.
>
> For the 2.5.1 release I will make a note that the 2.5.0 part of the
> changelog should be regenerated too to pick up the corrections.
>
>
> > I have filed a few small bugs which I just set the fixVersion to 2.5.1
> and
> > will try to get PRs out for soon, but we could also push them out if
> > needed.
> >
> > I also have https://issues.apache.org/jira/browse/HBASE-27381
> <https://issues.apache.org/jira/browse/HBASE-27381>
> which would
> > be helpful to have opinions on since it might be worth fixing for 2.5.1
> if
> > possible. It's a recurrence of a past gnarly bug with some API
> > compatibility concerns.
> >
>
> +1 for removal. We should get this into the next 2.4 and 2.5 releases. I
> will defend the change.
>
> >
> > A 2.6.0 release this calendar year would be great! We have completed most
> > of the TLS work at this point. One other thing I was considering adding
> to
> > 2.6.0 was a backport of hbase-backups. There is a PR [2] from
> Mallikarjun,
> > we are currently evaluating internally. I think backporting to 2.x will
> > help get more exposure and contributions, since most people aren't
> running
> > 3.0-alpha and there's still a backlog of nice-to-haves in the "Phase 4"
> > jira [3] that have languished a bit. I realize this might even require a
> > VOTE thread given the past history? I was only going to bring it up if
> our
> > evaluation worked out, but seemed relevant to your 2.6.0 question.
> >
>
> Let's discuss what release criteria for TLS RPC might look like. We can set
> a tentative release date for 2.6.0 for the second week of December, with RC
> in the first week, to get things moving. Let's start a new thread on what
> kind of testing and qualification people would like to see. I have some
> thoughts on the minimum bar I would set as a RM.
>
> Regarding the proposed backport of hbase-backups, what I would suggest is
> raising a DISCUSS thread first. We shouldn't need a VOTE if we can get a
> consensus that the backport is fine, perhaps after giving the feature the
> usual qualification of "experimental" when performing a backport of this
> nature. An alternative viewpoint would be we should finish and polish the
> 3.0.0 release to ship backup. Help Duo finish it, get a 3.0.0 out that is
> not designated alpha. I do want to acknowledge the tradeoff... In order to
> make use of a backup feature released in 3.0.0, one would need to upgrade
> production to it, which may be a bridge too far; and so any significant use
> of it might be delayed, maybe for a long time, but if it were released in a
> 2.x version it would likely get near term evaluation. Anyway this would
> make a great separate DISCUSS thread :-) .
>
>
>
> >
> > [1]
> >
> >
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> <https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22>
> > [2] https://github.com/apache/hbase/pull/4770
> <https://github.com/apache/hbase/pull/4770>
> > [3] https://issues.apache.org/jira/browse/HBASE-17362
> <https://issues.apache.org/jira/browse/HBASE-17362>
> >
> > On Tue, Sep 27, 2022 at 11:13 AM Andrew Purtell <
> andrew.purtell@gmail.com>
> > wrote:
> >
> > > We are already flattening and the proposed change adds release
> artifacts
> > > for hadoop3 using a new “hadoop3” classifier — at least, that is the
> > plan,
> > > let’s see if it works — and so the changes are additive. The default
> > build,
> > > which downstreamers consume as of 2.5.0 and all previous releases,
> > remains
> > > unchanged with respect to its dependency set. I think this means the
> > > changes are additive and orthogonal. That said I’d be fine with waiting
> > > until 2.6.0 to introduce the hadoop3 variant… in which case I would
> begin
> > > work on 2.6.0RC0 for anticipated release this calendar year. YDYT?
> > >
> > > > On Sep 27, 2022, at 7:15 AM, 张铎 <pa...@gmail.com> wrote:
> > > >
> > > > But I think flatten the pom profiles itself is also useful? It does
> > > > not make sense(and also does not work...) to activate a profile which
> > > > pulls in jars that are different from the ones we depend at the time
> > > > when building the hbase artifacts...
> > > >
> > > > Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
> > > >
> > > >>
> > > >> Yes -- that's why I brought it up in this discussion. I think that
> we
> > > >> should either finish the effort before 2.5.1 or revert it from
> > > >> branch-2.5 until we have a more complete implementation in place.
> > > >>
> > > >>> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <
> > palomino219@gmail.com>
> > > wrote:
> > > >>>
> > > >>> We already include HBASE-27340 in branch-2.5... So in the 2.5.1
> > > >>> release we will flatten the pom file, if we do not revert this
> > > >>> commit...
> > > >>>
> > > >>> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> > > >>>>
> > > >>>> I am also concerned about the feature that squashes out the
> profiles
> > > from
> > > >>>> our poms. To me, specifying the maven profile at build time is a
> > part
> > > of
> > > >>>> the API contract that we should not break in a patch release. I’d
> > > like to
> > > >>>> see that feature integrated into the do-release tooling such that
> > two
> > > sets
> > > >>>> of squished artifacts/maven repos are produced. And of course,
> > > updating the
> > > >>>> docs to explain how these are consumed.
> > > >>>>
> > > >>>> Maybe we need a minor release line where we ship both the old
> style
> > > and the
> > > >>>> new style artifacts? We could do that with 2.5…
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Nick
> > > >>>>
> > > >>>> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <
> palomino219@gmail.com>
> > > wrote:
> > > >>>>
> > > >>>>> Thanks Andrew for taking care of this.
> > > >>>>>
> > > >>>>> For me there is an issue HBASE-27359, where we can publish
> > different
> > > >>>>> maven artifacts for hadoop2 and hadoop3, it can solve the problem
> > > >>>>> brought up by the phoenix guys. Do you think we should include
> this
> > > in
> > > >>>>> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late
> > for
> > > >>>>> 2.5.1, to publish different maven artifacts for hadoop2 and
> > hadoop3,
> > > >>>>> or we still keep 2.5.x as is, and include this in the up coming
> > 2.6.x
> > > >>>>> release line?
> > > >>>>>
> > > >>>>> Thanks.
> > > >>>>>
> > > >>>>> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
> > > >>>>>
> > > >>>>>>
> > > >>>>>> It has been about a month since 2.5.0 and there are ~42 issues
> > > >>>>>> <
> > > >>>>>
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> <https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)>
> > > <
> >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> <https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)>
> > >
> > > >>>>>>
> > > >>>>>> related to 2.5.1. This week I will be grooming the issue tracker
> > > for a RC
> > > >>>>>> next week.If you have any pending work for branch-2.5 that you
> > > would like
> > > >>>>>> to get in, please set the fix version accordingly.
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Best regards,
> > > >>>>>> Andrew
> > > >>>>>
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Unrest, ignorance distilled, nihilistic imbeciles -
> It's what we’ve earned
> Welcome, apocalypse, what’s taken you so long?
> Bring us the fitting end that we’ve been counting on
> - A23, Welcome, Apocalypse
>
Re: About time for 2.5.1
Posted by Andrew Purtell <ap...@apache.org>.
Thanks Bryan. Responses inline.
On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault
<bb...@hubspot.com.invalid> wrote:
> Thanks Andrew!
>
> One thing I noticed from 2.5.0 was that a few JIRAs were included in that
> release which did not have the proper fixVersions set (so did not show up
> in CHANGES.md). I fixed 4 of them before realizing that may not be the way
> we should handle it. See [1] for the 4 I fixed (which we could revert to
> 2.5.1 if appropriate), there may be others.
>
JIRA is supposed to be the canonical source of fix version data, so if
there have been mistakes, the most important thing to do is update JIRA
with corrections. If I understand you correctly this is what you were
doing, and that would be the correct course of action imho. Then, if there
was a significant omission from the changelog (something critical or
blocker, I would say), we could always put out another release announcement
indicating the changelog corrections, or just do that anyway.
For the 2.5.1 release I will make a note that the 2.5.0 part of the
changelog should be regenerated too to pick up the corrections.
> I have filed a few small bugs which I just set the fixVersion to 2.5.1 and
> will try to get PRs out for soon, but we could also push them out if
> needed.
>
> I also have https://issues.apache.org/jira/browse/HBASE-27381 which would
> be helpful to have opinions on since it might be worth fixing for 2.5.1 if
> possible. It's a recurrence of a past gnarly bug with some API
> compatibility concerns.
>
+1 for removal. We should get this into the next 2.4 and 2.5 releases. I
will defend the change.
>
> A 2.6.0 release this calendar year would be great! We have completed most
> of the TLS work at this point. One other thing I was considering adding to
> 2.6.0 was a backport of hbase-backups. There is a PR [2] from Mallikarjun,
> we are currently evaluating internally. I think backporting to 2.x will
> help get more exposure and contributions, since most people aren't running
> 3.0-alpha and there's still a backlog of nice-to-haves in the "Phase 4"
> jira [3] that have languished a bit. I realize this might even require a
> VOTE thread given the past history? I was only going to bring it up if our
> evaluation worked out, but seemed relevant to your 2.6.0 question.
>
Let's discuss what release criteria for TLS RPC might look like. We can set
a tentative release date for 2.6.0 for the second week of December, with RC
in the first week, to get things moving. Let's start a new thread on what
kind of testing and qualification people would like to see. I have some
thoughts on the minimum bar I would set as a RM.
Regarding the proposed backport of hbase-backups, what I would suggest is
raising a DISCUSS thread first. We shouldn't need a VOTE if we can get a
consensus that the backport is fine, perhaps after giving the feature the
usual qualification of "experimental" when performing a backport of this
nature. An alternative viewpoint would be we should finish and polish the
3.0.0 release to ship backup. Help Duo finish it, get a 3.0.0 out that is
not designated alpha. I do want to acknowledge the tradeoff... In order to
make use of a backup feature released in 3.0.0, one would need to upgrade
production to it, which may be a bridge too far; and so any significant use
of it might be delayed, maybe for a long time, but if it were released in a
2.x version it would likely get near term evaluation. Anyway this would
make a great separate DISCUSS thread :-) .
>
> [1]
>
> https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
> [2] https://github.com/apache/hbase/pull/4770
> [3] https://issues.apache.org/jira/browse/HBASE-17362
>
> On Tue, Sep 27, 2022 at 11:13 AM Andrew Purtell <an...@gmail.com>
> wrote:
>
> > We are already flattening and the proposed change adds release artifacts
> > for hadoop3 using a new “hadoop3” classifier — at least, that is the
> plan,
> > let’s see if it works — and so the changes are additive. The default
> build,
> > which downstreamers consume as of 2.5.0 and all previous releases,
> remains
> > unchanged with respect to its dependency set. I think this means the
> > changes are additive and orthogonal. That said I’d be fine with waiting
> > until 2.6.0 to introduce the hadoop3 variant… in which case I would begin
> > work on 2.6.0RC0 for anticipated release this calendar year. YDYT?
> >
> > > On Sep 27, 2022, at 7:15 AM, 张铎 <pa...@gmail.com> wrote:
> > >
> > > But I think flatten the pom profiles itself is also useful? It does
> > > not make sense(and also does not work...) to activate a profile which
> > > pulls in jars that are different from the ones we depend at the time
> > > when building the hbase artifacts...
> > >
> > > Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
> > >
> > >>
> > >> Yes -- that's why I brought it up in this discussion. I think that we
> > >> should either finish the effort before 2.5.1 or revert it from
> > >> branch-2.5 until we have a more complete implementation in place.
> > >>
> > >>> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <
> palomino219@gmail.com>
> > wrote:
> > >>>
> > >>> We already include HBASE-27340 in branch-2.5... So in the 2.5.1
> > >>> release we will flatten the pom file, if we do not revert this
> > >>> commit...
> > >>>
> > >>> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> > >>>>
> > >>>> I am also concerned about the feature that squashes out the profiles
> > from
> > >>>> our poms. To me, specifying the maven profile at build time is a
> part
> > of
> > >>>> the API contract that we should not break in a patch release. I’d
> > like to
> > >>>> see that feature integrated into the do-release tooling such that
> two
> > sets
> > >>>> of squished artifacts/maven repos are produced. And of course,
> > updating the
> > >>>> docs to explain how these are consumed.
> > >>>>
> > >>>> Maybe we need a minor release line where we ship both the old style
> > and the
> > >>>> new style artifacts? We could do that with 2.5…
> > >>>>
> > >>>> Thanks,
> > >>>> Nick
> > >>>>
> > >>>> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> > >>>>
> > >>>>> Thanks Andrew for taking care of this.
> > >>>>>
> > >>>>> For me there is an issue HBASE-27359, where we can publish
> different
> > >>>>> maven artifacts for hadoop2 and hadoop3, it can solve the problem
> > >>>>> brought up by the phoenix guys. Do you think we should include this
> > in
> > >>>>> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late
> for
> > >>>>> 2.5.1, to publish different maven artifacts for hadoop2 and
> hadoop3,
> > >>>>> or we still keep 2.5.x as is, and include this in the up coming
> 2.6.x
> > >>>>> release line?
> > >>>>>
> > >>>>> Thanks.
> > >>>>>
> > >>>>> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
> > >>>>>
> > >>>>>>
> > >>>>>> It has been about a month since 2.5.0 and there are ~42 issues
> > >>>>>> <
> > >>>>>
> >
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > <
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> >
> > >>>>>>
> > >>>>>> related to 2.5.1. This week I will be grooming the issue tracker
> > for a RC
> > >>>>>> next week.If you have any pending work for branch-2.5 that you
> > would like
> > >>>>>> to get in, please set the fix version accordingly.
> > >>>>>>
> > >>>>>> --
> > >>>>>> Best regards,
> > >>>>>> Andrew
> > >>>>>
> >
>
--
Best regards,
Andrew
Unrest, ignorance distilled, nihilistic imbeciles -
It's what we’ve earned
Welcome, apocalypse, what’s taken you so long?
Bring us the fitting end that we’ve been counting on
- A23, Welcome, Apocalypse
Re: About time for 2.5.1
Posted by Bryan Beaudreault <bb...@hubspot.com.INVALID>.
Thanks Andrew!
One thing I noticed from 2.5.0 was that a few JIRAs were included in that
release which did not have the proper fixVersions set (so did not show up
in CHANGES.md). I fixed 4 of them before realizing that may not be the way
we should handle it. See [1] for the 4 I fixed (which we could revert to
2.5.1 if appropriate), there may be others.
I have filed a few small bugs which I just set the fixVersion to 2.5.1 and
will try to get PRs out for soon, but we could also push them out if needed.
I also have https://issues.apache.org/jira/browse/HBASE-27381 which would
be helpful to have opinions on since it might be worth fixing for 2.5.1 if
possible. It's a recurrence of a past gnarly bug with some API
compatibility concerns.
A 2.6.0 release this calendar year would be great! We have completed most
of the TLS work at this point. One other thing I was considering adding to
2.6.0 was a backport of hbase-backups. There is a PR [2] from Mallikarjun,
we are currently evaluating internally. I think backporting to 2.x will
help get more exposure and contributions, since most people aren't running
3.0-alpha and there's still a backlog of nice-to-haves in the "Phase 4"
jira [3] that have languished a bit. I realize this might even require a
VOTE thread given the past history? I was only going to bring it up if our
evaluation worked out, but seemed relevant to your 2.6.0 question.
[1]
https://issues.apache.org/jira/browse/HBASE-27241?jql=text%20~%20%22%5C%22Seems%20this%20actually%20landed%20in%202.5.0%5C%22%22
[2] https://github.com/apache/hbase/pull/4770
[3] https://issues.apache.org/jira/browse/HBASE-17362
On Tue, Sep 27, 2022 at 11:13 AM Andrew Purtell <an...@gmail.com>
wrote:
> We are already flattening and the proposed change adds release artifacts
> for hadoop3 using a new “hadoop3” classifier — at least, that is the plan,
> let’s see if it works — and so the changes are additive. The default build,
> which downstreamers consume as of 2.5.0 and all previous releases, remains
> unchanged with respect to its dependency set. I think this means the
> changes are additive and orthogonal. That said I’d be fine with waiting
> until 2.6.0 to introduce the hadoop3 variant… in which case I would begin
> work on 2.6.0RC0 for anticipated release this calendar year. YDYT?
>
> > On Sep 27, 2022, at 7:15 AM, 张铎 <pa...@gmail.com> wrote:
> >
> > But I think flatten the pom profiles itself is also useful? It does
> > not make sense(and also does not work...) to activate a profile which
> > pulls in jars that are different from the ones we depend at the time
> > when building the hbase artifacts...
> >
> > Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
> >
> >>
> >> Yes -- that's why I brought it up in this discussion. I think that we
> >> should either finish the effort before 2.5.1 or revert it from
> >> branch-2.5 until we have a more complete implementation in place.
> >>
> >>> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
> >>>
> >>> We already include HBASE-27340 in branch-2.5... So in the 2.5.1
> >>> release we will flatten the pom file, if we do not revert this
> >>> commit...
> >>>
> >>> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> >>>>
> >>>> I am also concerned about the feature that squashes out the profiles
> from
> >>>> our poms. To me, specifying the maven profile at build time is a part
> of
> >>>> the API contract that we should not break in a patch release. I’d
> like to
> >>>> see that feature integrated into the do-release tooling such that two
> sets
> >>>> of squished artifacts/maven repos are produced. And of course,
> updating the
> >>>> docs to explain how these are consumed.
> >>>>
> >>>> Maybe we need a minor release line where we ship both the old style
> and the
> >>>> new style artifacts? We could do that with 2.5…
> >>>>
> >>>> Thanks,
> >>>> Nick
> >>>>
> >>>> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
> >>>>
> >>>>> Thanks Andrew for taking care of this.
> >>>>>
> >>>>> For me there is an issue HBASE-27359, where we can publish different
> >>>>> maven artifacts for hadoop2 and hadoop3, it can solve the problem
> >>>>> brought up by the phoenix guys. Do you think we should include this
> in
> >>>>> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late for
> >>>>> 2.5.1, to publish different maven artifacts for hadoop2 and hadoop3,
> >>>>> or we still keep 2.5.x as is, and include this in the up coming 2.6.x
> >>>>> release line?
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
> >>>>>
> >>>>>>
> >>>>>> It has been about a month since 2.5.0 and there are ~42 issues
> >>>>>> <
> >>>>>
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> <https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)>
> >>>>>>
> >>>>>> related to 2.5.1. This week I will be grooming the issue tracker
> for a RC
> >>>>>> next week.If you have any pending work for branch-2.5 that you
> would like
> >>>>>> to get in, please set the fix version accordingly.
> >>>>>>
> >>>>>> --
> >>>>>> Best regards,
> >>>>>> Andrew
> >>>>>
>
Re: About time for 2.5.1
Posted by Andrew Purtell <an...@gmail.com>.
We are already flattening and the proposed change adds release artifacts for hadoop3 using a new “hadoop3” classifier — at least, that is the plan, let’s see if it works — and so the changes are additive. The default build, which downstreamers consume as of 2.5.0 and all previous releases, remains unchanged with respect to its dependency set. I think this means the changes are additive and orthogonal. That said I’d be fine with waiting until 2.6.0 to introduce the hadoop3 variant… in which case I would begin work on 2.6.0RC0 for anticipated release this calendar year. YDYT?
> On Sep 27, 2022, at 7:15 AM, 张铎 <pa...@gmail.com> wrote:
>
> But I think flatten the pom profiles itself is also useful? It does
> not make sense(and also does not work...) to activate a profile which
> pulls in jars that are different from the ones we depend at the time
> when building the hbase artifacts...
>
> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
>
>>
>> Yes -- that's why I brought it up in this discussion. I think that we
>> should either finish the effort before 2.5.1 or revert it from
>> branch-2.5 until we have a more complete implementation in place.
>>
>>> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>>>
>>> We already include HBASE-27340 in branch-2.5... So in the 2.5.1
>>> release we will flatten the pom file, if we do not revert this
>>> commit...
>>>
>>> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
>>>>
>>>> I am also concerned about the feature that squashes out the profiles from
>>>> our poms. To me, specifying the maven profile at build time is a part of
>>>> the API contract that we should not break in a patch release. I’d like to
>>>> see that feature integrated into the do-release tooling such that two sets
>>>> of squished artifacts/maven repos are produced. And of course, updating the
>>>> docs to explain how these are consumed.
>>>>
>>>> Maybe we need a minor release line where we ship both the old style and the
>>>> new style artifacts? We could do that with 2.5…
>>>>
>>>> Thanks,
>>>> Nick
>>>>
>>>> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>>>>
>>>>> Thanks Andrew for taking care of this.
>>>>>
>>>>> For me there is an issue HBASE-27359, where we can publish different
>>>>> maven artifacts for hadoop2 and hadoop3, it can solve the problem
>>>>> brought up by the phoenix guys. Do you think we should include this in
>>>>> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late for
>>>>> 2.5.1, to publish different maven artifacts for hadoop2 and hadoop3,
>>>>> or we still keep 2.5.x as is, and include this in the up coming 2.6.x
>>>>> release line?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
>>>>>
>>>>>>
>>>>>> It has been about a month since 2.5.0 and there are ~42 issues
>>>>>> <
>>>>> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
>>>>>>
>>>>>> related to 2.5.1. This week I will be grooming the issue tracker for a RC
>>>>>> next week.If you have any pending work for branch-2.5 that you would like
>>>>>> to get in, please set the fix version accordingly.
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Andrew
>>>>>
Re: About time for 2.5.1
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
But I think flatten the pom profiles itself is also useful? It does
not make sense(and also does not work...) to activate a profile which
pulls in jars that are different from the ones we depend at the time
when building the hbase artifacts...
Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 19:48写道：
>
> Yes -- that's why I brought it up in this discussion. I think that we
> should either finish the effort before 2.5.1 or revert it from
> branch-2.5 until we have a more complete implementation in place.
>
> On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> >
> > We already include HBASE-27340 in branch-2.5... So in the 2.5.1
> > release we will flatten the pom file, if we do not revert this
> > commit...
> >
> > Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> > >
> > > I am also concerned about the feature that squashes out the profiles from
> > > our poms. To me, specifying the maven profile at build time is a part of
> > > the API contract that we should not break in a patch release. I’d like to
> > > see that feature integrated into the do-release tooling such that two sets
> > > of squished artifacts/maven repos are produced. And of course, updating the
> > > docs to explain how these are consumed.
> > >
> > > Maybe we need a minor release line where we ship both the old style and the
> > > new style artifacts? We could do that with 2.5…
> > >
> > > Thanks,
> > > Nick
> > >
> > > On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> > >
> > > > Thanks Andrew for taking care of this.
> > > >
> > > > For me there is an issue HBASE-27359, where we can publish different
> > > > maven artifacts for hadoop2 and hadoop3, it can solve the problem
> > > > brought up by the phoenix guys. Do you think we should include this in
> > > > branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late for
> > > > 2.5.1, to publish different maven artifacts for hadoop2 and hadoop3,
> > > > or we still keep 2.5.x as is, and include this in the up coming 2.6.x
> > > > release line?
> > > >
> > > > Thanks.
> > > >
> > > > Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
> > > >
> > > > >
> > > > > It has been about a month since 2.5.0 and there are ~42 issues
> > > > > <
> > > > https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > > >
> > > > > related to 2.5.1. This week I will be grooming the issue tracker for a RC
> > > > > next week.If you have any pending work for branch-2.5 that you would like
> > > > > to get in, please set the fix version accordingly.
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > >
Re: About time for 2.5.1
Posted by Nick Dimiduk <nd...@apache.org>.
Yes -- that's why I brought it up in this discussion. I think that we
should either finish the effort before 2.5.1 or revert it from
branch-2.5 until we have a more complete implementation in place.
On Tue, Sep 27, 2022 at 12:15 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>
> We already include HBASE-27340 in branch-2.5... So in the 2.5.1
> release we will flatten the pom file, if we do not revert this
> commit...
>
> Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
> >
> > I am also concerned about the feature that squashes out the profiles from
> > our poms. To me, specifying the maven profile at build time is a part of
> > the API contract that we should not break in a patch release. I’d like to
> > see that feature integrated into the do-release tooling such that two sets
> > of squished artifacts/maven repos are produced. And of course, updating the
> > docs to explain how these are consumed.
> >
> > Maybe we need a minor release line where we ship both the old style and the
> > new style artifacts? We could do that with 2.5…
> >
> > Thanks,
> > Nick
> >
> > On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> >
> > > Thanks Andrew for taking care of this.
> > >
> > > For me there is an issue HBASE-27359, where we can publish different
> > > maven artifacts for hadoop2 and hadoop3, it can solve the problem
> > > brought up by the phoenix guys. Do you think we should include this in
> > > branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late for
> > > 2.5.1, to publish different maven artifacts for hadoop2 and hadoop3,
> > > or we still keep 2.5.x as is, and include this in the up coming 2.6.x
> > > release line?
> > >
> > > Thanks.
> > >
> > > Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
> > >
> > > >
> > > > It has been about a month since 2.5.0 and there are ~42 issues
> > > > <
> > > https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > > >
> > > > related to 2.5.1. This week I will be grooming the issue tracker for a RC
> > > > next week.If you have any pending work for branch-2.5 that you would like
> > > > to get in, please set the fix version accordingly.
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > >
Re: About time for 2.5.1
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
We already include HBASE-27340 in branch-2.5... So in the 2.5.1
release we will flatten the pom file, if we do not revert this
commit...
Nick Dimiduk <nd...@apache.org> 于2022年9月27日周二 16:46写道：
>
> I am also concerned about the feature that squashes out the profiles from
> our poms. To me, specifying the maven profile at build time is a part of
> the API contract that we should not break in a patch release. I’d like to
> see that feature integrated into the do-release tooling such that two sets
> of squished artifacts/maven repos are produced. And of course, updating the
> docs to explain how these are consumed.
>
> Maybe we need a minor release line where we ship both the old style and the
> new style artifacts? We could do that with 2.5…
>
> Thanks,
> Nick
>
> On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>
> > Thanks Andrew for taking care of this.
> >
> > For me there is an issue HBASE-27359, where we can publish different
> > maven artifacts for hadoop2 and hadoop3, it can solve the problem
> > brought up by the phoenix guys. Do you think we should include this in
> > branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late for
> > 2.5.1, to publish different maven artifacts for hadoop2 and hadoop3,
> > or we still keep 2.5.x as is, and include this in the up coming 2.6.x
> > release line?
> >
> > Thanks.
> >
> > Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
> >
> > >
> > > It has been about a month since 2.5.0 and there are ~42 issues
> > > <
> > https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> > >
> > > related to 2.5.1. This week I will be grooming the issue tracker for a RC
> > > next week.If you have any pending work for branch-2.5 that you would like
> > > to get in, please set the fix version accordingly.
> > >
> > > --
> > > Best regards,
> > > Andrew
> >
Re: About time for 2.5.1
Posted by Nick Dimiduk <nd...@apache.org>.
I am also concerned about the feature that squashes out the profiles from
our poms. To me, specifying the maven profile at build time is a part of
the API contract that we should not break in a patch release. I’d like to
see that feature integrated into the do-release tooling such that two sets
of squished artifacts/maven repos are produced. And of course, updating the
docs to explain how these are consumed.
Maybe we need a minor release line where we ship both the old style and the
new style artifacts? We could do that with 2.5…
Thanks,
Nick
On Tue, Sep 27, 2022 at 03:40 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> Thanks Andrew for taking care of this.
>
> For me there is an issue HBASE-27359, where we can publish different
> maven artifacts for hadoop2 and hadoop3, it can solve the problem
> brought up by the phoenix guys. Do you think we should include this in
> branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late for
> 2.5.1, to publish different maven artifacts for hadoop2 and hadoop3,
> or we still keep 2.5.x as is, and include this in the up coming 2.6.x
> release line?
>
> Thanks.
>
> Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
>
> >
> > It has been about a month since 2.5.0 and there are ~42 issues
> > <
> https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)
> >
> > related to 2.5.1. This week I will be grooming the issue tracker for a RC
> > next week.If you have any pending work for branch-2.5 that you would like
> > to get in, please set the fix version accordingly.
> >
> > --
> > Best regards,
> > Andrew
>
Re: About time for 2.5.1
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
Thanks Andrew for taking care of this.
For me there is an issue HBASE-27359, where we can publish different
maven artifacts for hadoop2 and hadoop3, it can solve the problem
brought up by the phoenix guys. Do you think we should include this in
branch-2.5 and start from 2.5.1 or maybe 2.5.2 if it is too late for
2.5.1, to publish different maven artifacts for hadoop2 and hadoop3,
or we still keep 2.5.x as is, and include this in the up coming 2.6.x
release line?
Thanks.
Andrew Purtell <ap...@apache.org> 于2022年9月27日周二 06:52写道：
>
> It has been about a month since 2.5.0 and there are ~42 issues
> <https://issues.apache.org/jira/issues/?jql=project%3Dhbase%20and%20(%20fixVersion%3D2.5.1%20or%20affectedVersion%20%3D%202.5.1%20)>
> related to 2.5.1. This week I will be grooming the issue tracker for a RC
> next week.If you have any pending work for branch-2.5 that you would like
> to get in, please set the fix version accordingly.
>
> --
> Best regards,
> Andrew