Sounds good Duo. On Tue, Oct 4, 2022 at 5:15 AM 张铎(Duo Zhang) <palomino...@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 <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 > > > > -- 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
