Nothing stimulates the mind like an upcoming release: Since we have not yet released a 5.2 version which supports HBase 2.4.0 or pre 2.5.4 HBase versions, we could drop support for those. I have opened separate tickets for both:
https://issues.apache.org/jira/browse/PHOENIX-7218 for 2.4.0 https://issues.apache.org/jira/browse/PHOENIX-7219 for 2.5.3 I don't think anyone will miss 2.4.0 support, but we may want to keep HBase 2.5.0-2.5.3 as 2.5.3 is only a year old. Please share your opinion here or on the tickets. Istvan On Fri, Feb 16, 2024 at 7:50 AM Istvan Toth <st...@apache.org> wrote: > I agree, this is a few lines (if it works) which takes no time to > backport, so we need not hold up cutting the release branch for this. > > The HBase 2.5 and 2.5.0 profiles work fine with Hadoop 3.2.4, as expected, > so updating those is kind of a non-brainer. > > I see many errors on the 2.4.0 and 2.4 profile, but I'm not yet sure if > those are simply flakey, or if they are caused by the newer Hadoop. > > I haven't run the tests with Hadoop 3.3 yet. My HBase 3 WIP branch seems > to work fine with it, but HBase 3 itself is built with Hadoop 3.3, so > that's a different situation. > > I will report back when I have more results. > > Istvan > > > > On Fri, Feb 16, 2024 at 6:23 AM Viraj Jasani <vjas...@apache.org> wrote: > >> Sure let's go for it. I understand downstreamers are not happy with CVEs >> coming from our artifacts that were released in 2022. >> >> >> On Thu, Feb 15, 2024 at 6:05 PM rajeshb...@apache.org < >> chrajeshbab...@gmail.com> wrote: >> >>> Would be better to bump up Hadoop to 3.3.x I feel which has minimal >>> vulnerabilities compared to Hadoop 3.2.4. >>> >>> Thanks, >>> Rajeshbabu. >>> >>> On Fri, Feb 16, 2024, 7:25 AM Viraj Jasani <vjas...@apache.org> wrote: >>> >>> > Sure it sounds good to create PR for version upgrades while we are >>> getting >>> > close to releasing 5.2.0 and 5.1.4. >>> > However, if the build has unexpected test failures, we can cut 5.2 >>> first, >>> > and focus on stabilizing the upgrade changes on master branch PR rather >>> > than 5.2 branch, allowing faster release. >>> > >>> > Some new features like CDC and JSON support will anyway need 5.3 >>> release >>> > soon. >>> > >>> > >>> > On Thu, Feb 15, 2024 at 7:54 AM Istvan Toth <st...@apache.org> wrote: >>> > >>> > > This comment >>> > > <https://github.com/apache/phoenix/pull/1810#issuecomment-1945998086 >>> > >>> > got >>> > > me thinking. >>> > > >>> > > Most of the community (i.e. SFDC and CLDR) does not particularly care >>> > about >>> > > Hadoop and HBase dependency versions, as these are meant to be >>> overridden >>> > > anyway, >>> > > and we both build our own binaries. >>> > > However, for downstream projects that use Phoenix, old CVE-ridden >>> Hadoop >>> > > versions in the public maven artifacts can be a problem. >>> > > >>> > > While we cannot influence CVEs coming from Hadoop and HBase >>> (technically >>> > we >>> > > can, but it would be a bad idea to tamper with non-direct dependency >>> > > versions), >>> > > we can at least make sure that we use reasonably new Hadoop versions >>> for >>> > > building Phoenix (and including those in the public artifacts) >>> > > >>> > > Hbase branch-2.4 uses Hadoop 3.1.3 by default, but it switches to >>> 3.2.0 >>> > > when being built on JDK11+. >>> > > Hbase branch-2.5 uses Hadoop 3.2.4. (but we still use 3.2.3) >>> > > >>> > > Based on the above, I think that we should bump the default Hadoop >>> > version >>> > > to 3.2.4 for each supported HBase profile. >>> > > The main reason we stick to the Hbase Hadoop versions is that we've >>> often >>> > > been bitten by binary incompatibilities >>> > > between Hadoop minor versions, but I think that using the latest 3.2 >>> > point >>> > > release should be safe. >>> > > >>> > > If there are any problems, the tests will find them, most of those >>> > > incompatibilities manifest in minicluster anyway. >>> > > >>> > > What do you think ? >>> > > Can you think of anything that this would break ? >>> > > We can also discuss going straight to 3.3.x, but we can certainly run >>> > some >>> > > tests at least to see the results. >>> > > >>> > > I have opened https://issues.apache.org/jira/browse/PHOENIX-7216. >>> > > I suggest treating this as an 5.2 blocker (at least until we decide >>> not >>> > to) >>> > > >>> > > Istvan >>> > > >>> > > On Thu, Feb 15, 2024 at 8:49 AM Istvan Toth <st...@apache.org> >>> wrote: >>> > > >>> > > > I have committed PHOENIX-7191 (thanks for the review, Viraj). >>> > > > I have also put up a PR < >>> https://github.com/apache/phoenix/pull/1810> >>> > > for >>> > > > PHOENIX-7193. >>> > > > >>> > > > I was not able to test them comprehensively, as I am still >>> struggling >>> > > with >>> > > > some issues with HBase 3 where simple GETs >>> > > > initiated from a coprocessor hang until they time out, but I >>> wanted to >>> > > get >>> > > > the known fixes in to unblock 5.2. >>> > > > >>> > > > Istvan >>> > > > >>> > > > On Tue, Feb 13, 2024 at 6:24 AM Istvan Toth <st...@apache.org> >>> wrote: >>> > > > >>> > > >> We didn't really have such branches for past releases (that I have >>> > > >> followed), but we could change the practice. >>> > > >> >>> > > >> When I acted as an RM, I didn't feel the need to branch early, >>> but if >>> > it >>> > > >> helps your planned workflow, then sure. >>> > > >> At least it would remind us to actually complete the release in a >>> > > >> reasonable amount of time. >>> > > >> >>> > > >> Istvan >>> > > >> >>> > > >> On Tue, Feb 13, 2024 at 4:30 AM Viraj Jasani <vjas...@apache.org> >>> > > wrote: >>> > > >> >>> > > >>> No worries, that’s fine, both 5.2.0 and 5.1.4 can wait for non-zk >>> > > >>> registry >>> > > >>> fixes for a week or so. >>> > > >>> >>> > > >>> On the other hand, how about we still cut 5.2 branch now and keep >>> > > >>> backporting changes landing on master branch to 5.2 if necessary. >>> > Once >>> > > >>> non-zk registries are fixed, I can start with 5.2.0 release >>> > > preparation. >>> > > >>> >>> > > >>> >>> > > >>> On Sun, Feb 11, 2024 at 11:28 PM Istvan Toth <st...@apache.org> >>> > wrote: >>> > > >>> >>> > > >>> > Thank you, Viraj, >>> > > >>> > >>> > > >>> > 5.1.4 also has the non-ZK registries feature, and has the same >>> bugs >>> > > as >>> > > >>> 5.2 >>> > > >>> > in that code. >>> > > >>> > >>> > > >>> > >>> > > >>> > >>> > > >>> > On Sat, Feb 10, 2024 at 7:00 PM Viraj Jasani < >>> vjas...@apache.org> >>> > > >>> wrote: >>> > > >>> > >>> > > >>> > > Sure no worries, we can wait a few more days. >>> > > >>> > > >>> > > >>> > > In the meantime, I have merged the backport PR on 5.1 branch >>> for >>> > > the >>> > > >>> data >>> > > >>> > > integrity fixes. Once omid dependency change is in, I >>> believe we >>> > > are >>> > > >>> good >>> > > >>> > > to start with 5.1.4. >>> > > >>> > > >>> > > >>> > > Thank you Rajeshbabu for volunteering to take it up. >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > On Sat, Feb 10, 2024 at 1:28 AM Istvan Toth < >>> st...@apache.org> >>> > > >>> wrote: >>> > > >>> > > >>> > > >>> > >> I appreciate the drive to get 5.2.0 out of the door, but I >>> would >>> > > >>> prefer >>> > > >>> > to >>> > > >>> > >> have a few more days to fix the registry issues, >>> > > >>> > >> and run some tests on them before cutting the branch, Viraj. >>> > > >>> > >> The non-ZK registry support is one of the bigger new >>> features, >>> > and >>> > > >>> I'd >>> > > >>> > >> prefer not to have known breaking bugs in the release. >>> > > >>> > >> Can we target Friday or the next Monday for the cut ? >>> > > >>> > >> >>> > > >>> > >> Istvan >>> > > >>> > >> >>> > > >>> > >> On Sat, Feb 10, 2024 at 10:07 AM rajeshb...@apache.org < >>> > > >>> > >> chrajeshbab...@gmail.com> wrote: >>> > > >>> > >> >>> > > >>> > >> > Yes Viraj, I can release 5.1.4 >>> > > >>> > >> > >>> > > >>> > >> > Thanks, >>> > > >>> > >> > Rajeshbabu. >>> > > >>> > >> > >>> > > >>> > >> > On Sat, Feb 10, 2024, 10:28 AM Viraj Jasani < >>> > vjas...@apache.org >>> > > > >>> > > >>> > wrote: >>> > > >>> > >> > >>> > > >>> > >> >> I think we can also target 5.2.1 very soon, perhaps just >>> next >>> > > >>> month, >>> > > >>> > >> with >>> > > >>> > >> >> more CVE fixes and any other fixes if ready. >>> > > >>> > >> >> >>> > > >>> > >> >> >>> > > >>> > >> >> On Fri, Feb 9, 2024 at 6:39 PM Viraj Jasani < >>> > > vjas...@apache.org> >>> > > >>> > >> wrote: >>> > > >>> > >> >> >>> > > >>> > >> >> > For 5.2.0, it would be great to focus on the known data >>> > > >>> integrity >>> > > >>> > >> >> issues. >>> > > >>> > >> >> > We can fix non-zk registry, cover a few more CVEs by >>> > > upgrading >>> > > >>> > third >>> > > >>> > >> >> party >>> > > >>> > >> >> > dependencies and stabilize tests. As for the tests, >>> they >>> > > don’t >>> > > >>> seem >>> > > >>> > >> >> broken, >>> > > >>> > >> >> > but are flaky. I have got multiple builds without any >>> test >>> > > >>> failures >>> > > >>> > >> on >>> > > >>> > >> >> PR >>> > > >>> > >> >> > for PHOENIX-7106. >>> > > >>> > >> >> > >>> > > >>> > >> >> > If this looks good to you, I can start release >>> preparation >>> > > next >>> > > >>> > week. >>> > > >>> > >> >> What >>> > > >>> > >> >> > do you think, Istvan? >>> > > >>> > >> >> > >>> > > >>> > >> >> > In the meantime, I have 5.1 backport PR open, awaiting >>> good >>> > > >>> build >>> > > >>> > >> >> results >>> > > >>> > >> >> > before committing it. >>> > > >>> > >> >> > Rajeshbabu, would you like to be RM for 5.1.4 once the >>> PR >>> > is >>> > > >>> > merged? >>> > > >>> > >> >> > >>> > > >>> > >> >> > >>> > > >>> > >> >> > >>> > > >>> > >> >> > On Fri, Feb 9, 2024 at 11:13 AM Istvan Toth < >>> > > st...@apache.org> >>> > > >>> > >> wrote: >>> > > >>> > >> >> > >>> > > >>> > >> >> >> Yes, they basically make the non-ZK registries >>> unusable. >>> > > >>> > >> >> >> (at least the connectionless problems should be >>> fixed.) >>> > > >>> > >> >> >> >>> > > >>> > >> >> >> I hope to have the final fix for those sometime next >>> week. >>> > > >>> > >> >> >> >>> > > >>> > >> >> >> Also have we looked at potential CVE issues on master >>> > > >>> recently ? >>> > > >>> > >> >> >> >>> > > >>> > >> >> >> I think we should also look at the most flakey tests I >>> > > linked >>> > > >>> > above, >>> > > >>> > >> >> >> and fix them or at least make sure that they are test >>> > issues >>> > > >>> and >>> > > >>> > not >>> > > >>> > >> >> real >>> > > >>> > >> >> >> bugs. >>> > > >>> > >> >> >> >>> > > >>> > >> >> >> Istvan >>> > > >>> > >> >> >> >>> > > >>> > >> >> >> >>> > > >>> > >> >> >> >>> > > >>> > >> >> >> On Fri, Feb 9, 2024 at 6:55 PM Viraj Jasani < >>> > > >>> vjas...@apache.org> >>> > > >>> > >> >> wrote: >>> > > >>> > >> >> >> >>> > > >>> > >> >> >> > Thanks Istvan. >>> > > >>> > >> >> >> > I would like to cut 5.2 branch from master. Do you >>> see >>> > > >>> non-ZK >>> > > >>> > >> >> registry >>> > > >>> > >> >> >> for >>> > > >>> > >> >> >> > MapReduce jobs as blocker for 5.2.0? >>> > > >>> > >> >> >> > >>> > > >>> > >> >> >> > >>> > > >>> > >> >> >> > On Fri, Feb 9, 2024 at 12:24 AM Istvan Toth < >>> > > >>> st...@apache.org> >>> > > >>> > >> >> wrote: >>> > > >>> > >> >> >> > >>> > > >>> > >> >> >> > > >>> > > >>> > >> >>> > ParallelPhoenixConnectionFailureTest.testExecuteQueryChainFailure >>> > > >>> > >> >> also >>> > > >>> > >> >> >> > > fails too often, especially when the test host is >>> slow >>> > > >>> and/or >>> > > >>> > >> the >>> > > >>> > >> >> >> load is >>> > > >>> > >> >> >> > > high. >>> > > >>> > >> >> >> > > On my fast laptop, I can semi-reliably break it by >>> > > running >>> > > >>> > >> >> >> > > mvn clean verify -am -pl phoenix-core >>> -DnumForkedUT=20 >>> > > >>> > >> >> >> > > >>> > > >>> > >> >> >> > > On Fri, Feb 9, 2024 at 9:19 AM Istvan Toth < >>> > > >>> st...@apache.org> >>> > > >>> > >> >> wrote: >>> > > >>> > >> >> >> > > >>> > > >>> > >> >> >> > > > We're making progress. >>> > > >>> > >> >> >> > > > I can see that Viraj has just landed >>> PHOENIX-7601, >>> > and >>> > > >>> > >> Rajeshbabu >>> > > >>> > >> >> >> has >>> > > >>> > >> >> >> > > > released Omid 1.1.1. >>> > > >>> > >> >> >> > > > Thank you! >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > > At the moment, the following outstanding issues >>> are >>> > on >>> > > >>> my >>> > > >>> > >> radar: >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > > >>> https://issues.apache.org/jira/browse/PHOENIX-7191 >>> > > >>> > >> >> >> > > > >>> https://issues.apache.org/jira/browse/PHOENIX-7193 >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > > These are bugs in my non-ZK registry >>> implementation, >>> > > >>> which >>> > > >>> > >> were >>> > > >>> > >> >> >> found >>> > > >>> > >> >> >> > > > during HBase 3 work. >>> > > >>> > >> >> >> > > > I have some PRs up, but they may not be >>> complete. I >>> > > will >>> > > >>> > push >>> > > >>> > >> for >>> > > >>> > >> >> >> > reviews >>> > > >>> > >> >> >> > > > once I have the HBase 3 tests passing, and >>> possibly >>> > > >>> updated >>> > > >>> > >> them >>> > > >>> > >> >> >> based >>> > > >>> > >> >> >> > on >>> > > >>> > >> >> >> > > > that. >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > > We also have a number of very flakey tests, see: >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > >>> > > >>> > >> >> >> > >>> > > >>> > >> >> >> >>> > > >>> > >> >> >>> > > >>> > >> >>> > > >>> > >>> > > >>> >>> > > >>> > >>> https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-mulitbranch/job/master/test_results_analyzer/ >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > > On Tue, Jan 30, 2024 at 7:09 AM Istvan Toth < >>> > > >>> > >> st...@cloudera.com> >>> > > >>> > >> >> >> > wrote: >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > >> As Viraj wrote, those are just plans. >>> > > >>> > >> >> >> > > >> If HBase 3 won't be released by the time the >>> other >>> > > >>> features >>> > > >>> > >> are >>> > > >>> > >> >> >> ready, >>> > > >>> > >> >> >> > > >> then it won't make it into 5.3. >>> > > >>> > >> >> >> > > >> If other major features are ready by that time, >>> > then >>> > > >>> they >>> > > >>> > >> will >>> > > >>> > >> >> be >>> > > >>> > >> >> >> > > >> included. (though we are not aware of any now) >>> > > >>> > >> >> >> > > >> >>> > > >>> > >> >> >> > > >> As for the new major version, in the past >>> Phoenix >>> > > >>> didn't >>> > > >>> > >> have a >>> > > >>> > >> >> >> > > >> compatibility module system, >>> > > >>> > >> >> >> > > >> so a new branch was required, which didn't >>> support >>> > > >>> older >>> > > >>> > >> >> HBases. >>> > > >>> > >> >> >> > Also, >>> > > >>> > >> >> >> > > >> the API changes between HBase 1.x and 2.x were >>> much >>> > > >>> larger, >>> > > >>> > >> >> >> > > >> The HBase 2 and 3 API are pretty similar, apart >>> > from >>> > > >>> the >>> > > >>> > >> >> removal of >>> > > >>> > >> >> >> > > >> deprecated 1.x APIs. (and the protobuf/protocol >>> > > thing, >>> > > >>> > which >>> > > >>> > >> >> >> requires >>> > > >>> > >> >> >> > a >>> > > >>> > >> >> >> > > >> rather ugly hack). >>> > > >>> > >> >> >> > > >> >>> > > >>> > >> >> >> > > >> I will start the discussion on how we can add >>> > HBase 3 >>> > > >>> > >> support as >>> > > >>> > >> >> >> soon >>> > > >>> > >> >> >> > as >>> > > >>> > >> >> >> > > >> I have a working POC patch. >>> > > >>> > >> >> >> > > >> >>> > > >>> > >> >> >> > > >> We could call 5.3 6.0 instead, after all >>> Phoenix >>> > > isn't >>> > > >>> > using >>> > > >>> > >> a >>> > > >>> > >> >> >> strict >>> > > >>> > >> >> >> > > >> semantic versioning, but then 6.0 would also >>> > support >>> > > >>> HBase >>> > > >>> > 2. >>> > > >>> > >> >> >> > > >> If we do not come to a consensus on the version >>> > name, >>> > > >>> we >>> > > >>> > can >>> > > >>> > >> >> always >>> > > >>> > >> >> >> > have >>> > > >>> > >> >> >> > > >> a vote on it. >>> > > >>> > >> >> >> > > >> >>> > > >>> > >> >> >> > > >> I think that the main motivation is that the >>> > > community >>> > > >>> > wants >>> > > >>> > >> to >>> > > >>> > >> >> >> > maintain >>> > > >>> > >> >> >> > > >> as few branches as possible. >>> > > >>> > >> >> >> > > >> >>> > > >>> > >> >> >> > > >> Istvan >>> > > >>> > >> >> >> > > >> >>> > > >>> > >> >> >> > > >> On Mon, Jan 29, 2024 at 10:02 PM Stephen Jiang >>> < >>> > > >>> > >> >> >> > syuanjiang...@gmail.com >>> > > >>> > >> >> >> > > > >>> > > >>> > >> >> >> > > >> wrote: >>> > > >>> > >> >> >> > > >> >>> > > >>> > >> >> >> > > >>> I am not sure how close HBase 3.0 is. Even >>> if it >>> > is >>> > > >>> only >>> > > >>> > >> less >>> > > >>> > >> >> >> than >>> > > >>> > >> >> >> > one >>> > > >>> > >> >> >> > > >>> year away, the adoption would be low at the >>> > > >>> beginning. I >>> > > >>> > >> don't >>> > > >>> > >> >> >> think >>> > > >>> > >> >> >> > > 5.3 >>> > > >>> > >> >> >> > > >>> should wait for that. And traditionally, >>> Phoenix >>> > > >>> would >>> > > >>> > >> have a >>> > > >>> > >> >> >> major >>> > > >>> > >> >> >> > > >>> release to support the HBase major release >>> (4.x >>> > for >>> > > >>> HBase >>> > > >>> > >> 1.x >>> > > >>> > >> >> and >>> > > >>> > >> >> >> 5.x >>> > > >>> > >> >> >> > > for >>> > > >>> > >> >> >> > > >>> HBase 2.x), in this case, we are talking about >>> > > >>> Phoenix 6.0 >>> > > >>> > >> for >>> > > >>> > >> >> >> HBase >>> > > >>> > >> >> >> > > 3.0. >>> > > >>> > >> >> >> > > >>> >>> > > >>> > >> >> >> > > >>> Maybe we should adopt the HBase release model: >>> > > master >>> > > >>> > branch >>> > > >>> > >> >> for >>> > > >>> > >> >> >> next >>> > > >>> > >> >> >> > > >>> major >>> > > >>> > >> >> >> > > >>> release (6.0) and branch-5.x branch for next >>> 5.x >>> > > minor >>> > > >>> > >> release >>> > > >>> > >> >> and >>> > > >>> > >> >> >> > > >>> branch-5.2 for 5.2 minor release. >>> > > >>> > >> >> >> > > >>> >>> > > >>> > >> >> >> > > >>> Thanks >>> > > >>> > >> >> >> > > >>> Stephen >>> > > >>> > >> >> >> > > >>> >>> > > >>> > >> >> >> > > >>> >>> > > >>> > >> >> >> > > >>> >>> > > >>> > >> >> >> > > >>> On Thu, Jan 25, 2024 at 11:50 PM Viraj Jasani >>> < >>> > > >>> > >> >> vjas...@apache.org >>> > > >>> > >> >> >> > >>> > > >>> > >> >> >> > > >>> wrote: >>> > > >>> > >> >> >> > > >>> >>> > > >>> > >> >> >> > > >>> > Sounds good. >>> > > >>> > >> >> >> > > >>> > >>> > > >>> > >> >> >> > > >>> > Planned major changes for 5.3.0: >>> > > >>> > >> >> >> > > >>> > >>> > > >>> > >> >> >> > > >>> > 1. JSON support. >>> > > >>> > >> >> >> > > >>> > 2. HBase 3.0 support. >>> > > >>> > >> >> >> > > >>> > 3. CDC feature (leveraging uncovered global >>> > index >>> > > >>> > >> framework >>> > > >>> > >> >> and >>> > > >>> > >> >> >> > JSON >>> > > >>> > >> >> >> > > >>> > support). >>> > > >>> > >> >> >> > > >>> > >>> > > >>> > >> >> >> > > >>> > >>> > > >>> > >> >> >> > > >>> > On Wed, Jan 24, 2024 at 8:22 PM Kadir >>> Ozdemir >>> > > >>> > >> >> >> > > >>> > <kozde...@salesforce.com.invalid> wrote: >>> > > >>> > >> >> >> > > >>> > >>> > > >>> > >> >> >> > > >>> > > I suggest including another major change >>> for >>> > > 5.3, >>> > > >>> > >> Phoenix >>> > > >>> > >> >> CDC, >>> > > >>> > >> >> >> > > >>> > > >>> > > >>> https://issues.apache.org/jira/browse/PHOENIX-7001. >>> > > >>> > >> The PR >>> > > >>> > >> >> >> for >>> > > >>> > >> >> >> > it >>> > > >>> > >> >> >> > > >>> will >>> > > >>> > >> >> >> > > >>> > be >>> > > >>> > >> >> >> > > >>> > > posted soon. >>> > > >>> > >> >> >> > > >>> > > >>> > > >>> > >> >> >> > > >>> > > On Thu, Jan 25, 2024 at 5:35 AM Viraj >>> Jasani < >>> > > >>> > >> >> >> vjas...@apache.org >>> > > >>> > >> >> >> > > >>> > > >>> > >> >> >> > > >>> wrote: >>> > > >>> > >> >> >> > > >>> > > >>> > > >>> > >> >> >> > > >>> > > > Thanks Istvan! I agree with your points. >>> > It’s >>> > > >>> really >>> > > >>> > >> >> been a >>> > > >>> > >> >> >> > while >>> > > >>> > >> >> >> > > >>> we >>> > > >>> > >> >> >> > > >>> > are >>> > > >>> > >> >> >> > > >>> > > > talking about releasing 5.2.0 and yet >>> due to >>> > > >>> > bandwidth >>> > > >>> > >> >> >> issues, >>> > > >>> > >> >> >> > > >>> unable >>> > > >>> > >> >> >> > > >>> > to >>> > > >>> > >> >> >> > > >>> > > do >>> > > >>> > >> >> >> > > >>> > > > so. >>> > > >>> > >> >> >> > > >>> > > > >>> > > >>> > >> >> >> > > >>> > > > I agree to getting these fixes out, cut >>> 5.2 >>> > > and >>> > > >>> > start >>> > > >>> > >> the >>> > > >>> > >> >> >> > release >>> > > >>> > >> >> >> > > >>> work >>> > > >>> > >> >> >> > > >>> > > and >>> > > >>> > >> >> >> > > >>> > > > in the meantime I also need to prepare >>> 5.1 >>> > > >>> backport. >>> > > >>> > >> >> >> > > >>> > > > >>> > > >>> > >> >> >> > > >>> > > > For 5.3, let's plan HBase 3.0 support >>> and >>> > JSON >>> > > >>> as >>> > > >>> > >> major >>> > > >>> > >> >> >> > changes. >>> > > >>> > >> >> >> > > >>> > > > >>> > > >>> > >> >> >> > > >>> > > > >>> > > >>> > >> >> >> > > >>> > > > On Mon, Jan 22, 2024 at 9:17 PM Istvan >>> Toth >>> > < >>> > > >>> > >> >> >> st...@apache.org> >>> > > >>> > >> >> >> > > >>> wrote: >>> > > >>> > >> >> >> > > >>> > > > >>> > > >>> > >> >> >> > > >>> > > > > Hi! >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > > In my opinion cutting 5.2 now only >>> makes >>> > > >>> sense IF >>> > > >>> > >> we DO >>> > > >>> > >> >> >> NOT >>> > > >>> > >> >> >> > > plan >>> > > >>> > >> >> >> > > >>> to >>> > > >>> > >> >> >> > > >>> > > > release >>> > > >>> > >> >> >> > > >>> > > > > the outstanding big features (like >>> JSON) >>> > in >>> > > >>> 5.2. , >>> > > >>> > >> >> >> otherwise >>> > > >>> > >> >> >> > > it's >>> > > >>> > >> >> >> > > >>> > just >>> > > >>> > >> >> >> > > >>> > > > > extra work to maintain more branches. >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > > Having said that, releasing a 5.2 and >>> > 5.1.4 >>> > > >>> with >>> > > >>> > the >>> > > >>> > >> >> data >>> > > >>> > >> >> >> > > >>> integrity >>> > > >>> > >> >> >> > > >>> > > fixes >>> > > >>> > >> >> >> > > >>> > > > > real soon, and then releasing 5.3 in >>> a few >>> > > >>> months >>> > > >>> > >> with >>> > > >>> > >> >> >> JSON, >>> > > >>> > >> >> >> > > and >>> > > >>> > >> >> >> > > >>> any >>> > > >>> > >> >> >> > > >>> > > > other >>> > > >>> > >> >> >> > > >>> > > > > outstanding big features >>> > > >>> > >> >> >> > > >>> > > > > that are close to being finished (and >>> > HBase >>> > > >>> 3.0 >>> > > >>> > >> >> support, >>> > > >>> > >> >> >> if >>> > > >>> > >> >> >> > > it's >>> > > >>> > >> >> >> > > >>> > ready >>> > > >>> > >> >> >> > > >>> > > by >>> > > >>> > >> >> >> > > >>> > > > > then) would not be a bad idea. >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > > On the CLDR side the only outstanding >>> big >>> > > >>> feature >>> > > >>> > >> which >>> > > >>> > >> >> >> could >>> > > >>> > >> >> >> > > >>> impact >>> > > >>> > >> >> >> > > >>> > > > > Viraj's integrity work is HBase 3.0 >>> > support, >>> > > >>> and >>> > > >>> > >> even >>> > > >>> > >> >> >> that is >>> > > >>> > >> >> >> > > >>> only >>> > > >>> > >> >> >> > > >>> > > > because >>> > > >>> > >> >> >> > > >>> > > > > it may require some larger refactors >>> of >>> > > >>> existing >>> > > >>> > >> code, >>> > > >>> > >> >> not >>> > > >>> > >> >> >> > > >>> because it >>> > > >>> > >> >> >> > > >>> > > > would >>> > > >>> > >> >> >> > > >>> > > > > change the actual behaviour or >>> algorithms. >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > > Phoenix used to have several minor >>> > releases >>> > > >>> per >>> > > >>> > >> year, >>> > > >>> > >> >> the >>> > > >>> > >> >> >> > > current >>> > > >>> > >> >> >> > > >>> > state >>> > > >>> > >> >> >> > > >>> > > > of >>> > > >>> > >> >> >> > > >>> > > > > extreme longevity of 5.1 and several >>> big >>> > new >>> > > >>> > >> features >>> > > >>> > >> >> >> being >>> > > >>> > >> >> >> > > >>> added to >>> > > >>> > >> >> >> > > >>> > it >>> > > >>> > >> >> >> > > >>> > > > > (like uncovered indexes) is not ideal. >>> > > >>> > >> >> >> > > >>> > > > > Releasing 5.2 and 5.3 relatively close >>> > > >>> together >>> > > >>> > >> could >>> > > >>> > >> >> be a >>> > > >>> > >> >> >> > > >>> return to >>> > > >>> > >> >> >> > > >>> > a >>> > > >>> > >> >> >> > > >>> > > > > quicker cadence for minor releases, >>> which >>> > > >>> could >>> > > >>> > also >>> > > >>> > >> >> help >>> > > >>> > >> >> >> > with >>> > > >>> > >> >> >> > > >>> the >>> > > >>> > >> >> >> > > >>> > > public >>> > > >>> > >> >> >> > > >>> > > > > image and adoption of Phoenix. >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > > We were talking about releasing 5.2 at >>> > > least a >>> > > >>> > year >>> > > >>> > >> >> ago, >>> > > >>> > >> >> >> and >>> > > >>> > >> >> >> > I >>> > > >>> > >> >> >> > > >>> have >>> > > >>> > >> >> >> > > >>> > > > started >>> > > >>> > >> >> >> > > >>> > > > > working on that then, but then >>> emergencies >>> > > >>> have >>> > > >>> > come >>> > > >>> > >> >> up at >>> > > >>> > >> >> >> > > >>> $dayjob, >>> > > >>> > >> >> >> > > >>> > > and I >>> > > >>> > >> >> >> > > >>> > > > > could not see that through. >>> > > >>> > >> >> >> > > >>> > > > > (So I am in part responsible for the >>> lack >>> > of >>> > > >>> minor >>> > > >>> > >> >> >> releases) >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > > regards >>> > > >>> > >> >> >> > > >>> > > > > Istvan >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > > On Mon, Jan 22, 2024 at 11:35 PM Viraj >>> > > Jasani >>> > > >>> < >>> > > >>> > >> >> >> > > >>> vjas...@apache.org> >>> > > >>> > >> >> >> > > >>> > > > wrote: >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > > > Sorry for the late reply. >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > Do you think cutting 5.2.0 now >>> makes >>> > > >>> sense? >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > No problem with that. I can cut 5.2 >>> > branch >>> > > >>> by >>> > > >>> > the >>> > > >>> > >> >> end of >>> > > >>> > >> >> >> > this >>> > > >>> > >> >> >> > > >>> week >>> > > >>> > >> >> >> > > >>> > or >>> > > >>> > >> >> >> > > >>> > > > at >>> > > >>> > >> >> >> > > >>> > > > > > the start of next week. >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > If there is any very big change or >>> > feature >>> > > >>> ready >>> > > >>> > >> for >>> > > >>> > >> >> >> merge >>> > > >>> > >> >> >> > to >>> > > >>> > >> >> >> > > >>> > master >>> > > >>> > >> >> >> > > >>> > > > > branch >>> > > >>> > >> >> >> > > >>> > > > > > with PR approvals already in place, >>> > please >>> > > >>> do >>> > > >>> > let >>> > > >>> > >> me >>> > > >>> > >> >> >> know >>> > > >>> > >> >> >> > so >>> > > >>> > >> >> >> > > >>> that I >>> > > >>> > >> >> >> > > >>> > > can >>> > > >>> > >> >> >> > > >>> > > > > > help collaborate on how best we can >>> get >>> > it >>> > > >>> > merged >>> > > >>> > >> >> >> without >>> > > >>> > >> >> >> > > >>> impacting >>> > > >>> > >> >> >> > > >>> > > 5.2 >>> > > >>> > >> >> >> > > >>> > > > > > release if required. My main >>> motivation >>> > > was >>> > > >>> for >>> > > >>> > >> any >>> > > >>> > >> >> big >>> > > >>> > >> >> >> > > change >>> > > >>> > >> >> >> > > >>> to >>> > > >>> > >> >> >> > > >>> > go >>> > > >>> > >> >> >> > > >>> > > > > > through newly introduced tests so >>> that >>> > we >>> > > >>> know >>> > > >>> > >> that >>> > > >>> > >> >> >> > anything >>> > > >>> > >> >> >> > > >>> > > additional >>> > > >>> > >> >> >> > > >>> > > > > is >>> > > >>> > >> >> >> > > >>> > > > > > not broken, and also to prioritize >>> for >>> > > >>> upcoming >>> > > >>> > >> 5.2.0 >>> > > >>> > >> >> >> and >>> > > >>> > >> >> >> > > 5.1.4 >>> > > >>> > >> >> >> > > >>> > > > releases. >>> > > >>> > >> >> >> > > >>> > > > > > Moreover, there are several PRs >>> getting >>> > > >>> merged >>> > > >>> > on >>> > > >>> > >> the >>> > > >>> > >> >> >> > master >>> > > >>> > >> >> >> > > >>> > branch, >>> > > >>> > >> >> >> > > >>> > > we >>> > > >>> > >> >> >> > > >>> > > > > can >>> > > >>> > >> >> >> > > >>> > > > > > continue that as long as they are >>> not >>> > very >>> > > >>> big >>> > > >>> > >> >> changes, >>> > > >>> > >> >> >> > which >>> > > >>> > >> >> >> > > >>> might >>> > > >>> > >> >> >> > > >>> > > > > require >>> > > >>> > >> >> >> > > >>> > > > > > significant time to understand any >>> > > >>> correlation >>> > > >>> > >> with >>> > > >>> > >> >> data >>> > > >>> > >> >> >> > > >>> integrity >>> > > >>> > >> >> >> > > >>> > > > > issues. >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > The PR is also ready for review with >>> > some >>> > > >>> > >> additional >>> > > >>> > >> >> >> cases >>> > > >>> > >> >> >> > > >>> fixed >>> > > >>> > >> >> >> > > >>> > last >>> > > >>> > >> >> >> > > >>> > > > > week: >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > >>> > > >>> > >> >> >> > > >>> > > >>> > > >>> > >> >> >> > > >>> > >>> > > >>> > >> >> >> > > >>> >>> > > >>> > >> >> >> > > >>> > > >>> > >> >> >> > >>> > > >>> > >> >> >> >>> > > >>> > >> >> >>> > > >>> > >> >>> > > >>> > >>> > > >>> >>> > > >>> > >>> https://urldefense.com/v3/__https://github.com/apache/phoenix/pull/1736__;!!DCbAVzZNrAf4!D4OVjUp2EWW2BqhGnBxsapDX_AHsibRphIpoFBWfgRsd3dsAikrFLo6PGxdTzGbSXJJ2fJ0j9mcz3asXMXo$ >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > Depending on the review bandwidth, >>> I am >>> > > >>> hopeful >>> > > >>> > we >>> > > >>> > >> >> >> should >>> > > >>> > >> >> >> > be >>> > > >>> > >> >> >> > > >>> good >>> > > >>> > >> >> >> > > >>> > to >>> > > >>> > >> >> >> > > >>> > > > land >>> > > >>> > >> >> >> > > >>> > > > > > them sooner. >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > On Wed, Jan 17, 2024 at 11:31 AM >>> Rushabh >>> > > >>> Shah >>> > > >>> > >> >> >> > > >>> > > > > > <rushabh.s...@salesforce.com >>> .invalid> >>> > > >>> wrote: >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > Thank you Viraj for initiating >>> this >>> > > >>> thread. >>> > > >>> > >> >> >> > > >>> > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > Given the critical nature of >>> these >>> > > >>> issues, I >>> > > >>> > >> >> would >>> > > >>> > >> >> >> like >>> > > >>> > >> >> >> > > to >>> > > >>> > >> >> >> > > >>> > > propose >>> > > >>> > >> >> >> > > >>> > > > > that >>> > > >>> > >> >> >> > > >>> > > > > > > we >>> > > >>> > >> >> >> > > >>> > > > > > > treat this as a high priority for >>> the >>> > > >>> upcoming >>> > > >>> > >> >> 5.2.0 >>> > > >>> > >> >> >> > > >>> release, and >>> > > >>> > >> >> >> > > >>> > > not >>> > > >>> > >> >> >> > > >>> > > > > > > include any other feature or big >>> > change >>> > > to >>> > > >>> > >> master >>> > > >>> > >> >> >> branch >>> > > >>> > >> >> >> > > >>> until we >>> > > >>> > >> >> >> > > >>> > > > merge >>> > > >>> > >> >> >> > > >>> > > > > > > this. >>> > > >>> > >> >> >> > > >>> > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > Do you think cutting 5.2.0 now >>> makes >>> > > >>> sense? >>> > > >>> > This >>> > > >>> > >> >> will >>> > > >>> > >> >> >> > > enable >>> > > >>> > >> >> >> > > >>> > other >>> > > >>> > >> >> >> > > >>> > > > > > > developers to merge features into >>> > master >>> > > >>> > branch >>> > > >>> > >> >> >> (5.3.0) >>> > > >>> > >> >> >> > and >>> > > >>> > >> >> >> > > >>> you >>> > > >>> > >> >> >> > > >>> > can >>> > > >>> > >> >> >> > > >>> > > > > take >>> > > >>> > >> >> >> > > >>> > > > > > > some more time to make sure we >>> cover >>> > all >>> > > >>> the >>> > > >>> > >> corner >>> > > >>> > >> >> >> cases >>> > > >>> > >> >> >> > > >>> for the >>> > > >>> > >> >> >> > > >>> > > > data >>> > > >>> > >> >> >> > > >>> > > > > > > integrity issues that you >>> uncovered. >>> > > >>> > >> >> >> > > >>> > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > On Fri, Jan 5, 2024 at 6:38 PM >>> Viraj >>> > > >>> Jasani < >>> > > >>> > >> >> >> > > >>> vjas...@apache.org> >>> > > >>> > >> >> >> > > >>> > > > > wrote: >>> > > >>> > >> >> >> > > >>> > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > Sounds good, thanks Rajeshbabu. >>> I >>> > will >>> > > >>> try >>> > > >>> > to >>> > > >>> > >> get >>> > > >>> > >> >> >> the >>> > > >>> > >> >> >> > > >>> first PR >>> > > >>> > >> >> >> > > >>> > > out >>> > > >>> > >> >> >> > > >>> > > > > next >>> > > >>> > >> >> >> > > >>> > > > > > > > week and while reviews happen in >>> > > >>> parallel, >>> > > >>> > >> will >>> > > >>> > >> >> try >>> > > >>> > >> >> >> to >>> > > >>> > >> >> >> > > get >>> > > >>> > >> >> >> > > >>> 5.1 >>> > > >>> > >> >> >> > > >>> > PR >>> > > >>> > >> >> >> > > >>> > > > > soon. >>> > > >>> > >> >> >> > > >>> > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > On Wed, Jan 3, 2024 at 8:49 PM >>> > > >>> > >> >> >> rajeshb...@apache.org < >>> > > >>> > >> >> >> > > >>> > > > > > > > chrajeshbab...@gmail.com> >>> wrote: >>> > > >>> > >> >> >> > > >>> > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > Hi Viraj, >>> > > >>> > >> >> >> > > >>> > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > Would be better to include the >>> > > >>> changes in >>> > > >>> > >> 5.1.4 >>> > > >>> > >> >> >> as >>> > > >>> > >> >> >> > in >>> > > >>> > >> >> >> > > >>> any >>> > > >>> > >> >> >> > > >>> > way >>> > > >>> > >> >> >> > > >>> > > it >>> > > >>> > >> >> >> > > >>> > > > > > will >>> > > >>> > >> >> >> > > >>> > > > > > > > take >>> > > >>> > >> >> >> > > >>> > > > > > > > > at least 3-4 days to complete >>> the >>> > > omid >>> > > >>> > >> release. >>> > > >>> > >> >> >> > > >>> > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > Thanks, >>> > > >>> > >> >> >> > > >>> > > > > > > > > Rajeshbabu. >>> > > >>> > >> >> >> > > >>> > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > On Thu, Jan 4, 2024 at 5:06 AM >>> > Viraj >>> > > >>> > Jasani >>> > > >>> > >> < >>> > > >>> > >> >> >> > > >>> > > vjas...@apache.org> >>> > > >>> > >> >> >> > > >>> > > > > > > wrote: >>> > > >>> > >> >> >> > > >>> > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > Thank you Kadir and >>> Geoffrey for >>> > > >>> your >>> > > >>> > >> >> replies!! >>> > > >>> > >> >> >> > > >>> > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > How does this affect >>> 5.1.4, >>> > > which >>> > > >>> is >>> > > >>> > >> also >>> > > >>> > >> >> >> listed >>> > > >>> > >> >> >> > as >>> > > >>> > >> >> >> > > >>> a Fix >>> > > >>> > >> >> >> > > >>> > > > > Version >>> > > >>> > >> >> >> > > >>> > > > > > > for >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > PHOENIX-7106? >>> > > >>> > >> >> >> > > >>> > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > Yes, it also needs to be >>> ported >>> > to >>> > > >>> 5.1. >>> > > >>> > >> Once >>> > > >>> > >> >> the >>> > > >>> > >> >> >> > > >>> master PR >>> > > >>> > >> >> >> > > >>> > is >>> > > >>> > >> >> >> > > >>> > > > up >>> > > >>> > >> >> >> > > >>> > > > > > for >>> > > >>> > >> >> >> > > >>> > > > > > > > > final >>> > > >>> > >> >> >> > > >>> > > > > > > > > > review, I would start >>> working on >>> > > the >>> > > >>> > >> backport >>> > > >>> > >> >> >> PR. >>> > > >>> > >> >> >> > > >>> > > > > > > > > > We just need some more >>> > additional >>> > > >>> > testing >>> > > >>> > >> to >>> > > >>> > >> >> >> ensure >>> > > >>> > >> >> >> > > old >>> > > >>> > >> >> >> > > >>> > > client >>> > > >>> > >> >> >> > > >>> > > > > > (e.g. >>> > > >>> > >> >> >> > > >>> > > > > > > > > 5.1.3) >>> > > >>> > >> >> >> > > >>> > > > > > > > > > is compatible with the new >>> > server >>> > > >>> with >>> > > >>> > the >>> > > >>> > >> >> >> changes. >>> > > >>> > >> >> >> > > >>> > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > Hence, yes it is now a >>> blocker >>> > for >>> > > >>> > >> upcoming >>> > > >>> > >> >> >> 5.1.4 >>> > > >>> > >> >> >> > as >>> > > >>> > >> >> >> > > >>> well >>> > > >>> > >> >> >> > > >>> > > since >>> > > >>> > >> >> >> > > >>> > > > > > 5.1.4 >>> > > >>> > >> >> >> > > >>> > > > > > > > RC >>> > > >>> > >> >> >> > > >>> > > > > > > > > > preparation is still pending >>> > > (while >>> > > >>> Omid >>> > > >>> > >> >> >> release is >>> > > >>> > >> >> >> > > in >>> > > >>> > >> >> >> > > >>> > > > progress). >>> > > >>> > >> >> >> > > >>> > > > > > > > > > Otherwise if 5.1.4 was >>> ready for >>> > > >>> > release, >>> > > >>> > >> I >>> > > >>> > >> >> >> would >>> > > >>> > >> >> >> > > have >>> > > >>> > >> >> >> > > >>> > > proposed >>> > > >>> > >> >> >> > > >>> > > > > > > > immediate >>> > > >>> > >> >> >> > > >>> > > > > > > > > > 5.1.5 release to include the >>> > > changes >>> > > >>> > >> proposed >>> > > >>> > >> >> >> with >>> > > >>> > >> >> >> > > >>> > > > PHOENIX-7106. >>> > > >>> > >> >> >> > > >>> > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > On Wed, Jan 3, 2024 at >>> 3:08 PM >>> > > >>> Geoffrey >>> > > >>> > >> >> Jacoby < >>> > > >>> > >> >> >> > > >>> > > > > gjac...@apache.org >>> > > >>> > >> >> >> > > >>> > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > wrote: >>> > > >>> > >> >> >> > > >>> > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > I agree that data >>> integrity >>> > > issues >>> > > >>> > are a >>> > > >>> > >> >> >> higher >>> > > >>> > >> >> >> > > >>> priority >>> > > >>> > >> >> >> > > >>> > > than >>> > > >>> > >> >> >> > > >>> > > > > > > feature >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > development, so I also >>> support >>> > > the >>> > > >>> > >> >> decision. >>> > > >>> > >> >> >> The >>> > > >>> > >> >> >> > > fact >>> > > >>> > >> >> >> > > >>> > that >>> > > >>> > >> >> >> > > >>> > > > > > several >>> > > >>> > >> >> >> > > >>> > > > > > > of >>> > > >>> > >> >> >> > > >>> > > > > > > > > the >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > major remaining 5.2 >>> features >>> > are >>> > > >>> > >> currently >>> > > >>> > >> >> >> being >>> > > >>> > >> >> >> > > >>> > developed >>> > > >>> > >> >> >> > > >>> > > in >>> > > >>> > >> >> >> > > >>> > > > > > > > > > long-running >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > feature branches also >>> helps, >>> > as >>> > > >>> work >>> > > >>> > can >>> > > >>> > >> >> >> continue >>> > > >>> > >> >> >> > > >>> there >>> > > >>> > >> >> >> > > >>> > at >>> > > >>> > >> >> >> > > >>> > > > the >>> > > >>> > >> >> >> > > >>> > > > > > cost >>> > > >>> > >> >> >> > > >>> > > > > > > > of >>> > > >>> > >> >> >> > > >>> > > > > > > > > a >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > rebase later. >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > How does this affect >>> 5.1.4, >>> > > which >>> > > >>> is >>> > > >>> > >> also >>> > > >>> > >> >> >> listed >>> > > >>> > >> >> >> > as >>> > > >>> > >> >> >> > > >>> a Fix >>> > > >>> > >> >> >> > > >>> > > > > Version >>> > > >>> > >> >> >> > > >>> > > > > > > for >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > PHOENIX-7106? From the bug >>> > > >>> description >>> > > >>> > >> it >>> > > >>> > >> >> also >>> > > >>> > >> >> >> > > sounds >>> > > >>> > >> >> >> > > >>> > like >>> > > >>> > >> >> >> > > >>> > > > > 5.1.3 >>> > > >>> > >> >> >> > > >>> > > > > > > and >>> > > >>> > >> >> >> > > >>> > > > > > > > > the >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > forthcoming .4 are >>> affected, >>> > > >>> since we >>> > > >>> > >> have >>> > > >>> > >> >> >> > > >>> server-side >>> > > >>> > >> >> >> > > >>> > > paging >>> > > >>> > >> >> >> > > >>> > > > > in >>> > > >>> > >> >> >> > > >>> > > > > > > 5.1. >>> > > >>> > >> >> >> > > >>> > > > > > > > > > (Feel >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > free to move that to a >>> > separate >>> > > >>> thread >>> > > >>> > >> if >>> > > >>> > >> >> you >>> > > >>> > >> >> >> > feel >>> > > >>> > >> >> >> > > it >>> > > >>> > >> >> >> > > >>> > > should >>> > > >>> > >> >> >> > > >>> > > > > be a >>> > > >>> > >> >> >> > > >>> > > > > > > > > > separate >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > discussion.) Should this >>> be a >>> > > >>> blocker >>> > > >>> > >> for >>> > > >>> > >> >> >> > releasing >>> > > >>> > >> >> >> > > >>> > 5.1.4? >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > Geoffrey >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > On Wed, Jan 3, 2024 at >>> 5:06 PM >>> > > >>> Kadir >>> > > >>> > >> >> Ozdemir < >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > >>> ka...@gsuite.cloud.apache.org >>> > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > wrote: >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > Being a database, >>> Phoenix >>> > has >>> > > to >>> > > >>> > make >>> > > >>> > >> >> sure >>> > > >>> > >> >> >> that >>> > > >>> > >> >> >> > > the >>> > > >>> > >> >> >> > > >>> > data >>> > > >>> > >> >> >> > > >>> > > > > stays >>> > > >>> > >> >> >> > > >>> > > > > > on >>> > > >>> > >> >> >> > > >>> > > > > > > > > disk >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > intact and its queries >>> > return >>> > > >>> > correct >>> > > >>> > >> >> data. >>> > > >>> > >> >> >> In >>> > > >>> > >> >> >> > > this >>> > > >>> > >> >> >> > > >>> > case, >>> > > >>> > >> >> >> > > >>> > > > > > Phoenix >>> > > >>> > >> >> >> > > >>> > > > > > > > > fails >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > to >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > return correct data for >>> some >>> > > >>> queries >>> > > >>> > >> if >>> > > >>> > >> >> >> their >>> > > >>> > >> >> >> > > scans >>> > > >>> > >> >> >> > > >>> > > > > experience >>> > > >>> > >> >> >> > > >>> > > > > > > > region >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > movement. Now that we >>> know >>> > > these >>> > > >>> > data >>> > > >>> > >> >> >> integrity >>> > > >>> > >> >> >> > > >>> issues >>> > > >>> > >> >> >> > > >>> > > and >>> > > >>> > >> >> >> > > >>> > > > > how >>> > > >>> > >> >> >> > > >>> > > > > > to >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > reproduce >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > them, fixing them >>> should be >>> > > our >>> > > >>> > first >>> > > >>> > >> >> >> priority. >>> > > >>> > >> >> >> > > >>> So, I >>> > > >>> > >> >> >> > > >>> > > fully >>> > > >>> > >> >> >> > > >>> > > > > > > support >>> > > >>> > >> >> >> > > >>> > > > > > > > > > this >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > proposal. >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > On Wed, Jan 3, 2024 at >>> > > 10:58 PM >>> > > >>> > Viraj >>> > > >>> > >> >> >> Jasani < >>> > > >>> > >> >> >> > > >>> > > > > > vjas...@apache.org >>> > > >>> > >> >> >> > > >>> > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > wrote: >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > Hello, >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > I would like to bring >>> > > >>> PHOENIX-7106 >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > < >>> > > >>> > >> >> >> > > >>> > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > >>> > > >>> > >> >> >> > > >>> > > > > >>> > > >>> > >> >> >> > > >>> > > > >>> > > >>> > >> >> >> > > >>> > > >>> > > >>> > >> >> >> > > >>> > >>> > > >>> > >> >> >> > > >>> >>> > > >>> > >> >> >> > > >>> > > >>> > >> >> >> > >>> > > >>> > >> >> >> >>> > > >>> > >> >> >>> > > >>> > >> >>> > > >>> > >>> > > >>> >>> > > >>> > >>> https://urldefense.com/v3/__https://issues.apache.org/jira/browse/PHOENIX-7106__;!!DCbAVzZNrAf4!FZG5sv55IC1NqItQLY7GKWgUG2Do0gSta01gOiSdd36Dx3XHGtQx4M3c9visVXIt9DctPQzS-orob9vhzrCfVA$ >>> > > >>> > >> >> >> > > >>> > > > > > > > > to everyone's >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > attention here and >>> brief >>> > > >>> about the >>> > > >>> > >> data >>> > > >>> > >> >> >> > > integrity >>> > > >>> > >> >> >> > > >>> > > issues >>> > > >>> > >> >> >> > > >>> > > > > that >>> > > >>> > >> >> >> > > >>> > > > > > > we >>> > > >>> > >> >> >> > > >>> > > > > > > > > have >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > in >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > various coprocessors. >>> > > >>> Majority of >>> > > >>> > >> the >>> > > >>> > >> >> >> issues >>> > > >>> > >> >> >> > > are >>> > > >>> > >> >> >> > > >>> > > related >>> > > >>> > >> >> >> > > >>> > > > to >>> > > >>> > >> >> >> > > >>> > > > > > the >>> > > >>> > >> >> >> > > >>> > > > > > > > > fact >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > that >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > we do not return valid >>> > > rowkey >>> > > >>> for >>> > > >>> > >> >> certain >>> > > >>> > >> >> >> > > >>> queries. If >>> > > >>> > >> >> >> > > >>> > > any >>> > > >>> > >> >> >> > > >>> > > > > > > region >>> > > >>> > >> >> >> > > >>> > > > > > > > > > moves >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > in >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > the middle of the >>> scan, >>> > the >>> > > >>> HBase >>> > > >>> > >> >> client >>> > > >>> > >> >> >> > relies >>> > > >>> > >> >> >> > > >>> on >>> > > >>> > >> >> >> > > >>> > the >>> > > >>> > >> >> >> > > >>> > > > last >>> > > >>> > >> >> >> > > >>> > > > > > > > > returned >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > rowkey >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > and accordingly >>> changes >>> > the >>> > > >>> scan >>> > > >>> > >> >> >> boundaries >>> > > >>> > >> >> >> > > >>> while the >>> > > >>> > >> >> >> > > >>> > > > > scanner >>> > > >>> > >> >> >> > > >>> > > > > > > is >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > getting >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > reset to continue the >>> scan >>> > > >>> > >> operation. >>> > > >>> > >> >> If >>> > > >>> > >> >> >> the >>> > > >>> > >> >> >> > > >>> region >>> > > >>> > >> >> >> > > >>> > > does >>> > > >>> > >> >> >> > > >>> > > > > not >>> > > >>> > >> >> >> > > >>> > > > > > > > move, >>> > > >>> > >> >> >> > > >>> > > > > > > > > > scan >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > is >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > not expected to return >>> > > invalid >>> > > >>> > data, >>> > > >>> > >> >> >> however >>> > > >>> > >> >> >> > if >>> > > >>> > >> >> >> > > >>> the >>> > > >>> > >> >> >> > > >>> > > > region >>> > > >>> > >> >> >> > > >>> > > > > > > moves >>> > > >>> > >> >> >> > > >>> > > > > > > > in >>> > > >>> > >> >> >> > > >>> > > > > > > > > > the >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > middle of ongoing scan >>> > > >>> operation, >>> > > >>> > >> scan >>> > > >>> > >> >> >> would >>> > > >>> > >> >> >> > > >>> return >>> > > >>> > >> >> >> > > >>> > > > > > > > > invalid/incorrect >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > data >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > causing data integrity >>> > > issues. >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > Given the critical >>> nature >>> > of >>> > > >>> these >>> > > >>> > >> >> >> issues, I >>> > > >>> > >> >> >> > > >>> would >>> > > >>> > >> >> >> > > >>> > like >>> > > >>> > >> >> >> > > >>> > > > to >>> > > >>> > >> >> >> > > >>> > > > > > > > propose >>> > > >>> > >> >> >> > > >>> > > > > > > > > > that >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > we >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > treat this as a high >>> > > priority >>> > > >>> for >>> > > >>> > >> the >>> > > >>> > >> >> >> > upcoming >>> > > >>> > >> >> >> > > >>> 5.2.0 >>> > > >>> > >> >> >> > > >>> > > > > release, >>> > > >>> > >> >> >> > > >>> > > > > > > and >>> > > >>> > >> >> >> > > >>> > > > > > > > > not >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > include any other >>> feature >>> > or >>> > > >>> big >>> > > >>> > >> >> change to >>> > > >>> > >> >> >> > > master >>> > > >>> > >> >> >> > > >>> > > branch >>> > > >>> > >> >> >> > > >>> > > > > > until >>> > > >>> > >> >> >> > > >>> > > > > > > we >>> > > >>> > >> >> >> > > >>> > > > > > > > > > merge >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > this. The PR is still >>> not >>> > > >>> ready as >>> > > >>> > >> >> >> additional >>> > > >>> > >> >> >> > > >>> changes >>> > > >>> > >> >> >> > > >>> > > are >>> > > >>> > >> >> >> > > >>> > > > > > still >>> > > >>> > >> >> >> > > >>> > > > > > > > in >>> > > >>> > >> >> >> > > >>> > > > > > > > > my >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > local, requiring >>> rebase >>> > with >>> > > >>> the >>> > > >>> > >> >> current >>> > > >>> > >> >> >> > > master. >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > I would get back to >>> this >>> > > >>> discuss >>> > > >>> > >> >> thread as >>> > > >>> > >> >> >> > soon >>> > > >>> > >> >> >> > > >>> as >>> > > >>> > >> >> >> > > >>> > the >>> > > >>> > >> >> >> > > >>> > > PR >>> > > >>> > >> >> >> > > >>> > > > > and >>> > > >>> > >> >> >> > > >>> > > > > > > the >>> > > >>> > >> >> >> > > >>> > > > > > > > > doc >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > are >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > updated with the >>> latest >>> > > >>> findings >>> > > >>> > so >>> > > >>> > >> >> far. >>> > > >>> > >> >> >> The >>> > > >>> > >> >> >> > > >>> changes >>> > > >>> > >> >> >> > > >>> > > > > include >>> > > >>> > >> >> >> > > >>> > > > > > > many >>> > > >>> > >> >> >> > > >>> > > > > > > > > of >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > our >>> > > >>> > >> >> >> > > >>> > > > > > > > > > > > > coproc scanner >>> > > >>> implementations and >>> > > >>> > >> >> hence >>> > > >>> > >> >> >> it >>> > > > >> >>
