Congratulations and welcome, Rushabh!
> On Aug 15, 2023, at 1:46 PM, Viraj Jasani wrote:
>
> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Rushabh
> Shah has accepted the PMC's invitation to become a committer on Apache
> Phoenix.
>
> We appreciate all of the great
The CVE is for the c++ icu library not icu4j but ?
We did A where I work and it did what you’d expect and shut up the vuln
scanner.
+1 for B. The code is compatibly licensed and not that much. Other options
carry functionality loss risks or dev work. Dropping it in place is low risk
and low
.sh version> it will recompile the HBase dependency for Hadoop 3 and let a
> subsequent mvn test run work.
>
> I should have my vote up later today.
>
> Geoffrey
>
> On Thu, Oct 6, 2022 at 3:32 PM Andrew Purtell wrote:
>
> > +1 (binding)
> >
> >
+1 (binding)
* Signature: ok
* Checksum : ok
* Rat check (1.8.0_332): ok
- mvn clean apache-rat:check
* Built from source (1.8.0_332): ok
- mvn clean install -DskipTests
* Unit tests pass (1.8.0_332): failed
- mvn clean package
m the coprocessors) .
>
> Also, the coprocessor JARs don't have any Hbase or Hadoop code shaded in.
>
>
>
>> On Fri, Aug 26, 2022 at 5:45 AM Andrew Purtell
>> wrote:
>>
>> Is any OMID coprocessor code using Hadoop APIs?
>>
>>> On Aug 25, 2022, at 9:
Is any OMID coprocessor code using Hadoop APIs?
> On Aug 25, 2022, at 9:41 AM, Istvan Toth wrote:
>
> We dependencyManage every Hadoop component in Phoenix, so going to Hadoop3
> in Omid is not strictly necessary.
> Hadoop is also added to the TSO libraries in the assembly, but AFAIK
>
At my employer we maintain a fork of Phoenix that we try to keep as close
to open source as possible given our internal requirements. One issue we
are facing in recent months is a tightening corporate policy on the
presence of known software vulnerabilities in our dependencies. Of course,
this
Congratulations Gokcen.
On Tue, Jul 5, 2022 at 12:21 PM Geoffrey Jacoby wrote:
> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Gokcen
> Iskender
> has accepted our invitation to join the PMC.
>
> Please join me in congratulating Gokcen!
>
> Thanks,
>
> Geoffrey Jacoby
>
--
I will post 2.4.12RC0 tomorrow in fact.
On Thu, Apr 28, 2022 at 3:16 PM Josh Elser wrote:
> Definitely makes sense to drop 2.1 and 2.2 (which are long gone in
> upstream support).
>
> 2.3 isn't mentioned on HBase downloads.html anymore so I think that's
> also good to go, but 2.4 is still very
Thanks, I understand better.
> What I am proposing is keeping phoenix-client-embedded, but dropping the
legacy (non embedded) phoenix-client jar/artifact from 5.2.
+1, for what it's worth. Embedding a logging back end is a bad idea as we
have learned. Only the facade (SLF4J) should be necessary.
It shouldn't be necessary to shade the logger, if you are using SLF4J
everywhere as logging facade in Phoenix, as I believe you are. Exclude
log4j and reload4j for shading into the client jar, and supply them in lib/
instead in your convenience artifact. The user can opt to include them on
the
Reload4J might be an acceptable solution if you need a CVE free logging
back end with log4j1 compatibility.
On Wed, Jan 12, 2022 at 6:16 AM Istvan Toth wrote:
> Hi!
>
> While we have avoided the worst of the recent Log4j2 vulnerabilities, due
> to using the long abandoned Log4j1 libraries, we
As someone who investigated an internal mitigation for pulling up Tephra to a
newer Guava version, and decided it was too much work after hitting some Twill
issues in the process, I feel your pain directly and enthusiastically +1
removal.
> On Jan 4, 2022, at 7:46 AM, Josh Elser wrote:
>
>
Congratulations, Viraj!
> On Jun 18, 2021, at 1:26 PM, Ankit Singhal wrote:
>
> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Viraj
> Jasani
> has accepted our invitation to join the PMC.
>
> Please join me in congratulating Viraj.
>
> Thanks,
> Ankit Singhal
Congratulations and welcome, Jacob.
On Wed, Jun 2, 2021 at 8:17 PM Xinyi Yan wrote:
> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Jacob
> Isaac has accepted the PMC's invitation to become a committer on Apache
> Phoenix.
>
> We appreciate all of the great contributions
think there is a problem with existing design. The only
> thing I wanted to make sure, HBase 1 and 2 don't have any behavioural
> change in the workflow (other than HBase 1 using coproc endpoint directly
> on RS vs HBase 2 using Admin APIs).
>
>> On Mon, May 31, 2021 at 10:07 PM And
In the HBase security unit tests we wait for the zk mediated cache reload to
complete before continuing the test. If you don’t do that your test will be
flaky. Check that you are doing this. If you are not, then your tests will be
flaky. In the real world, the operator issues the grant or
Congratulations Xinyi.
> On Mar 31, 2021, at 10:32 AM, Chinmay Kulkarni
> wrote:
>
> Xinyi
3.0 and 3.1, as I have seen similar errors when building
> Phoenix with Hadoop 3.1
> against an HBase built for Hadoop 3.0 (I did not save the error, or opened
> an HBase ticket for it at the time, unfortunately, only noted it in
> PHOENIX-6333)
>
> Istvan
>
>
> On Sat, Mar
Because the Async WAL module will not link with Hadoop 3 jars if it has been
compiled for Hadoop 2, Phoenix builds that download the Hadoop 3 and HBase 2
jars from public repositories will not work. Tests cannot run during the Maven
verify phase because the minicluster will terminate with
A.Private, I could not argue from HBase side to
> bring methods back in HStore. If we can do it in 2.4.2, that would be great
> and we can skip 2.4.1 support i think.
> WDYT Istvan?
>
>
>> On Wed, 17 Feb 2021 at 3:28 AM, Andrew Purtell wrote:
>>
>> Hmm... I see. T
Hmm... I see. This thread is probably about PHOENIX-6359, so the change was
HBASE-25249.
The methods moved from HStore to StoreUtils can be added back to HStore as
compatibility methods in branch-2.4.
Is there more?
On Tue, Feb 16, 2021 at 1:34 PM Andrew Purtell wrote:
> > While supp
> While supporting a new HBase patch release version (e.g 2.4.1), if it
turns out to be incompatible with existing HBase minor release profile (e.g
profile 2.4), we might have to consider some extra steps.
What happened? If we broke something in a public or limited private
interface between 2.4.0
Congratulations, Viraj!
> On Feb 9, 2021, at 2:07 PM, Geoffrey Jacoby wrote:
>
> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Viraj
> Jasani has accepted the PMC's invitation to become a committer on Apache
> Phoenix.
>
> We appreciate all of the great contributions Viraj
So it's time to enforce an automatic revert if build fails policy?
Ideally, no commit before a precommit passes.
If that fails, if someone discovers failing tests and can git bisect to the
cause, automatic revert of the offending commit.
YDYT?
On Sun, Jun 14, 2020 at 10:20 PM Istvan Toth
Apache mailing list software stripps embedded images. Please post text.
On Mon, Jun 15, 2020 at 10:24 AM swaroopa kadam
wrote:
> Hi,
>
> I am trying to compile the master branch of phoenix and I get the
> following error message.
> What has changed recently? Do I need to make additional
Hit this today too. It's not enough to place phoenix-server.jar on the
classpath, now you also have to select the appropriate compatibility module
and add it too. At the least installation documentation should be updated.
On Fri, May 15, 2020 at 3:48 PM la...@apache.org wrote:
> This is the
, but it would be
> fundamentally the same Java/JVM combination)
>
> regards
> Istvan
>
>> On Wed, Apr 22, 2020 at 7:29 AM Andrew Purtell
>> wrote:
>>
>> Yes, what I was trying to say is even if you don't adopt 8 language
>> features and specify
: my employer doesn't support recent Phoenix 4.x versions, so my
> opinions may be tinted by that.
>
> regards
> Istvan
>
>> On Wed, Apr 22, 2020 at 3:50 AM Andrew Purtell wrote:
>>
>> Just to be super clear:
>>
>>> Compile the
up.
On Tue, Apr 21, 2020 at 6:44 PM Andrew Purtell wrote:
> The main problem you will face is the convenience binaries.
>
> If you are planning to move to Java 8, for 4.x branches, then you will no
> longer be able to make binary convenience releases compatible with any
> HBase 1.x
The main problem you will face is the convenience binaries.
If you are planning to move to Java 8, for 4.x branches, then you will no
longer be able to make binary convenience releases compatible with any
HBase 1.x convenience binary, even if you don't adopt any Java 8 language
features. Compile
Congratulations on the new role Ankit.
On Thu, Apr 16, 2020 at 8:14 AM Josh Elser wrote:
> I'm pleased to announce that the ASF board has just approved the
> transition of VP Phoenix from myself to Ankit. As with all things, this
> comes with the approval of the Phoenix PMC.
>
> The ASF defines
Since you have already done this great work, and 1.3 isn’t dead yet, and won’t
be “this year”, and it serves as an example of how to bring in entire new
features on later code lines, perhaps it should go in. Just my 0.02.
> On Feb 19, 2020, at 10:39 AM, Istvan Toth wrote:
>
> Geoffrey,
>
>
Congratulations and welcome, Gokcen!
On Mon, Feb 10, 2020 at 10:55 AM Geoffrey Jacoby wrote:
> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Gokcen
> Iskender has accepted our invitation to become a committer on the Phoenix
> project. Gokcen has contributed many features and
anches? But we still
> need to release multi src/bin tar for multi hbase versions?
>
> Andrew Purtell 于2020年1月15日周三 上午10:55写道：
>
>> Take PhoenixAccessController as an example. Over time the HBase interfaces
>> change in minor ways. You’ll need different compilation units
. It’s not a clever refactor
but is DRY. Over time this can be made cleaner case by case where the naive
transformation has a distasteful result.
> On Jan 14, 2020, at 6:40 PM, Andrew Purtell wrote:
>
It’s not necessary to abstract the HBase interfaces into a compatibility layer,
at least not to start. At each bump from one minor release to another a fix up
typically touches a handful of files. The jump from 1.x to 2.x is a bigger deal
but maybe there should still be separate branches for
Some of the python scripts are glorified shell scripts and could be
rewritten as such, such as the launch scripts for psql and sqlline and the
pqs. I get that python is and was trendier than bash but sometimes the
right tool for the job is the right tool for the job. Unlike python, bash
has a very
One thing I would like to suggest is a change to the project compatibility
policy for upgrade/downgrade to support the following:
Mixed client/server versions one minor release up or back. Going forward. So in
the future eg client={ 4.14, 4.15, 4.16 } <-> server={ 4.14, 4.15, 4.16 }. This
will
I can't answer for Lars but whenever version incompatibilities come up
usually only a handful of files are impacted. In the last round, the
Phoenix access controller, a related file in the same directory, and the
RPC scheduler. If you cloned these into separate version specific maven
modules case
I've done a fair amount of porting Phoenix among HBase versions. There are
a couple of ways to pull out differences. If you take the rather
heavyweight approach HBase does where there's a factory for compatibility
glue, and a facade for the essential functions, and then instantiations of
that
+0 (binding)
I support this but it isn't my time I'd be committing to maintaining the
new repos with a +1...
On Wed, Oct 30, 2019 at 8:27 AM Josh Elser wrote:
> Hi,
>
> As was previously discussed[1][2], there is a motion to "adopt" the
> Tephra and Omid podlings as sub-projects to Apache
Tephra and Omid are interesting in that they serve a similar function - a
transaction oracle - but scale differently per different choices in design,
so one is more appropriate for some kinds of transactional workloads vs the
other. It's akin to secondary indexing, there is not an index type that
e (maybe in a different thread) or offline. :-)
>
> Geoffrey
>
> On Fri, Jun 21, 2019 at 10:50 AM Andrew Purtell
> wrote:
>
> > Point of order Apache communities generally do not vote to achieve
> > consensus. That should be a last resort. Please do not vote to make these
Point of order Apache communities generally do not vote to achieve
consensus. That should be a last resort. Please do not vote to make these
kinds of decisions.
On Fri, Jun 21, 2019 at 12:15 AM Priyank Porwal
wrote:
> [Converting this thread to a community vote]
>
> I'd like to start Travis-CI
Travis is underpowered compared to ASF test infrastructure. Do the
integration tests run there?
Recommend using ASF infra and Yetus (yetus.apache.org). HBase provides a
completely worked example of how to integrate and use it for precommit.
On Fri, Jun 21, 2019 at 12:15 AM Priyank Porwal
wrote:
What I would recommend is take on branch as the canonical branch, I guess the
1.5 one since Lars says it’s testing out green. Find the common ancestor prior
to divergence. For all other branches reset the head to that ancestor and then
pick forward from 1.5 one commit at a time, fixing up for
Andrew Purtell created PHOENIX-5315:
---
Summary: Cross cluster replication of the base table only should
be sufficient
Key: PHOENIX-5315
URL: https://issues.apache.org/jira/browse/PHOENIX-5315
Congratulations and welcome, Kadir!
On Mon, Jun 3, 2019 at 9:57 AM Geoffrey Jacoby wrote:
> On behalf of the Apace Phoenix PMC, I am pleased to announce that Kadir
> Ozdemir has accepted our invitation to become a Phoenix committer. Kadir
> has already made a significant impact on the project,
Congratulations Swaroopa!
On Tue, May 28, 2019 at 2:38 PM Geoffrey Jacoby wrote:
> On behalf of the Apache Phoenix PMC, I am pleased to announce that Swaroopa
> Kadam has accepted our invitation to become a Phoenix committer. Swaroopa
> has contributed to a number of areas in the project,
[
https://issues.apache.org/jira/browse/PHOENIX-5298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5298:
Attachment: PHOENIX-5298-4.x-HBase-1.5.patch
> Branch 4.x-HBase-1.5 should incl
[
https://issues.apache.org/jira/browse/PHOENIX-5298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reassigned PHOENIX-5298:
---
Assignee: Andrew Purtell
Fix Version/s: 4.15.0
> Branch 4.x-HBase-
Let me raise this on dev@hbase
On Fri, May 24, 2019 at 11:45 AM Thomas D'Silva
wrote:
> We can't commit PHOENIX-5269 to 4.14-HBase-1.3 until HBase 1.3.5 is
> released.
>
> On Fri, May 24, 2019 at 5:21 AM Mihir Monani
> wrote:
>
> > I think we can't commit this patch to 4.14.2-HBase-1.3 as
[
https://issues.apache.org/jira/browse/PHOENIX-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5300:
Fix Version/s: (was: 4.15.0)
> NoopStatisticsCollector shouldn't scan any r
[
https://issues.apache.org/jira/browse/PHOENIX-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5300:
Fix Version/s: 4.15.0
> NoopStatisticsCollector shouldn't scan any r
[
https://issues.apache.org/jira/browse/PHOENIX-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reassigned PHOENIX-5300:
---
Assignee: Rushabh S Shah
> NoopStatisticsCollector shouldn't scan any r
Andrew Purtell created PHOENIX-5298:
---
Summary: Branch 4.x-HBase-1.5 should include Apache snapshots in
dependency resolution
Key: PHOENIX-5298
URL: https://issues.apache.org/jira/browse/PHOENIX-5298
[
https://issues.apache.org/jira/browse/PHOENIX-5296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5296:
Description:
Unit and integration tests for functional areas where the implementation
Andrew Purtell created PHOENIX-5296:
---
Summary: Ensure store file reader refcount is zero at end of
relevant unit tests
Key: PHOENIX-5296
URL: https://issues.apache.org/jira/browse/PHOENIX-5296
[
https://issues.apache.org/jira/browse/PHOENIX-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reassigned PHOENIX-5291:
---
Assignee: Lars Hofhansl
> Some cases where Phoenix does close scann
[
https://issues.apache.org/jira/browse/PHOENIX-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5291:
Affects Version/s: 4.15.0
> Some cases where Phoenix does close scann
[
https://issues.apache.org/jira/browse/PHOENIX-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5291:
Affects Version/s: 4.14.2
4.14.1
Priority: Critical
Andrew Purtell created PHOENIX-5279:
---
Summary: [phoenix-queryserver] Update Avatica to 1.15.0
Key: PHOENIX-5279
URL: https://issues.apache.org/jira/browse/PHOENIX-5279
Project: Phoenix
+1
I would think it would be a drain on committer time to keep having to
accommodate interface differences on the EOL line.
> On May 10, 2019, at 1:28 PM, Thomas D'Silva
> wrote:
>
> Since HBase 1.2 is now end of life and we are creating a new branch to
> support HBase-1.5(PHOENIX-5277), I
[
https://issues.apache.org/jira/browse/PHOENIX-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5277:
Attachment: PHOENIX-5277-4.x.patch
> Fixups for interface changes in HBase
Andrew Purtell created PHOENIX-5277:
---
Summary: Fixups for interface changes in HBase 1.5
Key: PHOENIX-5277
URL: https://issues.apache.org/jira/browse/PHOENIX-5277
Project: Phoenix
Issue
[
https://issues.apache.org/jira/browse/PHOENIX-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reassigned PHOENIX-5269:
---
Assignee: Kiran Kumar Maturi (was: Andrew Purtell)
> PhoenixAccessControl
[
https://issues.apache.org/jira/browse/PHOENIX-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reassigned PHOENIX-5269:
---
Assignee: Andrew Purtell
> PhoenixAccessController should use AccessChec
[
https://issues.apache.org/jira/browse/PHOENIX-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5269:
Description:
PhoenixAccessController should use AccessChecker instead
Andrew Purtell created PHOENIX-5269:
---
Summary: PhoenixAccessController should use AccessChecker instead
of AccessControlClient for permission checks
Key: PHOENIX-5269
URL: https://issues.apache.org/jira/browse
Congratulations Mihir.
On Sat, Apr 27, 2019 at 5:42 PM Thomas D'Silva wrote:
> On behalf of the Apache Phoenix PMC, I am pleased to announce that
> Mihir Monani has accepted our invitation to become a committer.
> Mihir has done some nice work fixing several bugs related to indexing[1].
>
>
[
https://issues.apache.org/jira/browse/PHOENIX-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5253:
Attachment: PHOENIX-5253.patch
> Use Maven provided resource transformers for Apa
Andrew Purtell created PHOENIX-5253:
---
Summary: Use Maven provided resource transformers for Apache
LICENSE and NOTICE files
Key: PHOENIX-5253
URL: https://issues.apache.org/jira/browse/PHOENIX-5253
Congratulations Abhishek!
On Fri, Apr 5, 2019 at 10:46 AM Thomas D'Silva wrote:
> On behalf of the Apache Phoenix PMC, I am pleased to announce that
> Abhishek Singh
> Chouhan has accepted our invitation to become a committer. Abhishek has
> fixed several bugs[1] (including an important one
Andrew Purtell created PHOENIX-5215:
---
Summary: Remove and replace HTrace
Key: PHOENIX-5215
URL: https://issues.apache.org/jira/browse/PHOENIX-5215
Project: Phoenix
Issue Type: Bug
[
https://issues.apache.org/jira/browse/PHOENIX-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reopened PHOENIX-374:
I was trying to compile the 1.4 branch (4.x-HBase-1.4) and got this error:
[ERROR] Failed
+1
On Tue, Feb 5, 2019 at 8:41 AM Josh Elser wrote:
> All,
>
> Please take the time to review what I have below and propose any
> additions/modifications you think appropriate. Unless I hear requests
> otherwise, I'll submit this Monday (2019/02/11).
>
> For those who have the karma and
[
https://issues.apache.org/jira/browse/PHOENIX-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5119:
Comment: was deleted
(was: {color:red}-1 overall{color}. Here are the results
[
https://issues.apache.org/jira/browse/PHOENIX-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5119:
Attachment: PHOENIX-5119-4.x.patch
> Work around RpcScheduler interface differen
[
https://issues.apache.org/jira/browse/PHOENIX-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5119:
Attachment: PHOENIX-5119-4.x.patch
> Work around RpcScheduler interface differen
[
https://issues.apache.org/jira/browse/PHOENIX-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated PHOENIX-5119:
Attachment: (was: PHOENIX-5119-4.x.patch)
> Work around RpcScheduler interf
Andrew Purtell created PHOENIX-5119:
---
Summary: Work around RpcScheduler interface differences in HBase
1.5
Key: PHOENIX-5119
URL: https://issues.apache.org/jira/browse/PHOENIX-5119
Project: Phoenix
Congratulations and welcome, Akshita!
On Thu, Jan 17, 2019 at 10:42 AM Thomas D'Silva
wrote:
> On behalf of the Apache Phoenix PMC, I am pleased to announce that Akshita
> Malhotra has accepted our invitation to become a committer. Akshita has
> worked on improving our map reduce integration by
Congratulations and welcome, Karan.
On Tue, Dec 11, 2018 at 8:38 PM Thomas D'Silva wrote:
> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Karan
> Mehta has accepted our invitation to join the PMC. He has been working on
> enhancing the phoenix query server.
>
> Please join
Congratulations Jaanai!
On Mon, Dec 10, 2018 at 2:05 PM Thomas D'Silva wrote:
> On behalf of the Apache Phoenix PMC, I am pleased to announce that Jaanai
> Zhang has accepted our invitation to become a committer. He has found and
> fixed several bugs [1]. He is also very active on the mailing
Congratulations and welcome, Chinmay!
On Mon, Dec 10, 2018 at 1:45 PM Thomas D'Silva wrote:
> On behalf of the Apache Phoenix PMC, I am pleased to announce that Chinmay
> Kulkarni has accepted our invitation to become a committer. Chinmay has
> contributed several metadata management
+1
On Tue, Nov 13, 2018 at 3:21 PM Josh Elser wrote:
> Devs -- please take a glance at this. I received no input on what should
> go into the board report, so I wrote one myself. This is due tomorrow,
> so I'll be submitting it soon. Any review is appreciated!
>
>
>
> ## Description:
>
[
https://issues.apache.org/jira/browse/PHOENIX-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reassigned PHOENIX-3808:
---
Assignee: (was: Andrew Purtell)
> Implement chaos tests using HBase's hb
If possible please continue to release for one or more of the HBase 1.x
code lines. I have a feeling the HBase 1.xes will be in production for a
long time yet.
On Wed, Sep 26, 2018 at 11:42 AM Thomas D'Silva
wrote:
> Would we also release 4.15, or just a new 5.x release to support HBase
>
> adapter would be Apache Drill IMHO. They're up to a new enough version of
> Calcite (and off of their fork) so that this would be feasible and would
> provide immediate benefits on the query side.
>
> Thanks,
> James
>
> On Tue, Aug 28, 2018 at 1:38 PM Andrew Purtell
> wrote
On Mon, Aug 27, 2018 at 11:03 AM Josh Elser wrote:
> 2. Can Phoenix be the de-facto schema for SQL on HBase?
>
> We've long asserted "if you have to ask how Phoenix serializes data, you
> shouldn't be do it" (a nod that you have to write lots of code). What if
> we turn that on its head? Could
>
T
his is an issue for binary compatibility artifacts only.
Sigh. Just to be clear I meant binary *convenience* artifacts.
On Mon, Aug 6, 2018 at 4:09 PM Andrew Purtell wrote:
> See http://hbase.apache.org/book.html#hbase.versioning. Dependency
> Compatibility, required for minor
See http://hbase.apache.org/book.html#hbase.versioning. Dependency
Compatibility, required for minor and patch releases, includes:
*An upgrade of HBase will not require an incompatible upgrade of the Java
runtime.*
If we compile HBase with Java 8 or up and then ship the binaries to a
deployment
+1
On Wed, Aug 1, 2018 at 10:16 AM Josh Elser wrote:
> Given no further input, here's the draft board report. If no concerns,
> I'll be sending this out sooner than later.
>
> ---
>
> ## Description:
> - Apache Phoenix enables SQL-based OLTP and operational analytics for
> Apache Hadoop
>
>
With my work hat on I would request the 4.x line continue for as long as
HBase 1.x does. Probably it would be best if eventually there is only one
active 4.x branch that follows the HBase 1.x minor release progression. So
it would target 1.4 today, then 1.5, then 1.6 (and I'm not sure there will
[
https://issues.apache.org/jira/browse/PHOENIX-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530460#comment-16530460
]
Andrew Purtell commented on PHOENIX-4781:
-
Since we are here...
{noformat
[
https://issues.apache.org/jira/browse/PHOENIX-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reassigned PHOENIX-4781:
---
Assignee: Karan Mehta
> Phoenix client project's jar naming convention cau
[
https://issues.apache.org/jira/browse/PHOENIX-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530306#comment-16530306
]
Andrew Purtell commented on PHOENIX-4781:
-
POM changes lgtm, but we need py script changes too
Congratulations and welcome, Ohad!
> On Jun 11, 2018, at 7:09 PM, James Taylor wrote:
>
> On behalf of the Apache Phoenix PMC, I'm please to announce that Ohad
> Shacham has accepted our invitation to become a committer. He's been
> diligently working on integrating the Apache Omid transaction
Congratulations, Pedro!
> On Jun 11, 2018, at 7:15 PM, James Taylor wrote:
>
> On behalf of the Apache Phoenix PMC, I'm please to announce that Pedro
> Boado has accepted our invitation to join the PMC. He's been the force
> behind our recent support for CDH (and the reason we have support not
1 - 100 of 804 matches
Mail list logo
