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). 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 <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) > > > > >>>>>> > > >>>>>> 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
