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 <bbeaudrea...@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 <apurt...@apache.org> wrote: > > > Thanks Bryan. Responses inline. > > > > On Tue, Sep 27, 2022 at 11:31 AM Bryan Beaudreault > > <bbeaudrea...@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.purt...@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, 张铎 <palomino...@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 <ndimi...@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) < > > > palomino...@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 <ndimi...@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) < > > palomino...@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 <apurt...@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 > >
