Istvan, is it possible to get hadoop version bumped with 5.2.1? That would
provide sufficient time to focus on resolving any issues that arise? Or you
have already run tests with new hadoop version on hbase 2.5 profile?


On Thu, Feb 22, 2024 at 12:38 AM Istvan Toth <st...@apache.org> wrote:

> The 2.4.0 drop is committed.
> Since there was no consensus on the 5.2.0 removal, I've kept that.
>
> Regarding the Hadoop version update:
> I have not made as much progress with testing as I hoped.
> I have reduced the scope of PHOENIX-7216 to just the 2.5 profile, as that
> does not need more testing, and I want to get at least the latest Hadoop
> patch releases into 5.2.0/5.1.4.
>
> I also see a new commons-compress version update by dependabot.
>
>
> Istvan
>
>
> On Fri, Feb 16, 2024 at 6:24 PM Viraj Jasani <vjas...@apache.org> wrote:
>
>> +1 for dropping support for 2.4.0.
>> For 2.5.0-2.5.3, I think we might need more opinion?
>>
>>
>> On Fri, Feb 16, 2024 at 12:12 AM Istvan Toth <st...@apache.org> wrote:
>>
>>> 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:
>>>>>> > > >>> > >> >> >> >
>>>>>> > > >>> > >> >> >> > >
>>>>>> > > >>> > >>
>>>>>> > ParallelPhoenixConnectionFailu
>>>>>
>>>>> reTest.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
>>>>>> > >
>>>>>
>>>>>

Reply via email to