+1
If we're dropping Phoenix 4.x imminently, that means dropping HBase 1.x
and we should follow suit in Omid.
A "beta" HBase 3.0 is probably not too, too far away. I would consider
how "nice" the current shim logic is in Omid (i.e. is it actually
helpful? nice to work with? effective?), and
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 much alive.
On 4/19/22 11:32 AM, Geoffrey Jacoby wrote:
+1 to dropping support for 2.1 and 2.2.
Agree on your solution proposed, Istvan.
I think a Phoenix 5.2 is the right time to take that on, too.
On 4/26/22 2:21 PM, Andrew Purtell wrote:
Thanks, I understand better.
What I am proposing is keeping phoenix-client-embedded, but dropping the
legacy (non embedded) phoenix-client
[
https://issues.apache.org/jira/browse/PHOENIX-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-3654:
Summary: Client-side PQS discovery for thin client (was: Load Balancer for
thin client
Agreed. As the person who did the work of pulling Tephra in from the
incubator, I think we were already then in the state of "does someone
actually care about Tephra?".
Without digging into the archives, I think someone was interested, but
it seems like this never manifested.
+1 to remove
Hey Kadir,
I think your update might have squashed some of the generated language
pages. I've just pushed a new update.
Not a problem, just an FYI :)
On 10/7/21 4:09 PM, Kadir Ozdemir wrote:
We had the tech talk on Online Data Format Change in Phoenix today. The
slides and recording for
+1 (binding)
* Ran unit tests with Phoenix 5.1 against python 2.7, 3.7, and 3.8 (all
passed)
* Ran a basic write test in parallel (saw expected levels of performance)
* dev-support/run-source-ratcheck.sh passed, visual inspection of output
looks good
* xsum/sigs look good
On 8/18/21 12:44
Josh Elser created PHOENIX-6515:
---
Summary: Phoenix uses hbase-testing-util but does not list it as a
dependency
Key: PHOENIX-6515
URL: https://issues.apache.org/jira/browse/PHOENIX-6515
Project
[
https://issues.apache.org/jira/browse/PHOENIX-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-6503.
-
Resolution: Done
Applied! Thanks [~richardantal]
> Update Apache Phoenix News on the webs
I think the idea is that we would include a sqlline jar with the Phoenix
distribution. Context: we had some grief where a sqlline upgrade caused
user pain because they were relying on specific output from sqlline.
If we have the sqlline jar _not_ packaged inside phoenix-client, then
users can
+1 (binding)
* xsums/sigs are good
* can build from src
* src release looks ok (apache-rat:check)
On 5/15/21 1:53 PM, Viraj Jasani wrote:
Please vote on this Apache phoenix release candidate, phoenix-4.16.1RC11
The VOTE will remain open for at least 72 hours.
[ ] +1 Release this package as
[
https://issues.apache.org/jira/browse/PHOENIX-6473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-6473:
Fix Version/s: queryserver-6.0.0
> Add Hadoop JMXServlet as /jmx endpo
[
https://issues.apache.org/jira/browse/PHOENIX-6473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned PHOENIX-6473:
---
Assignee: Andor Molnar
> Add Hadoop JMXServlet as /jmx endpo
+1 (binding)
* Xsums/sigs work
* Keys works
* Source release looks fine
* Validated that cookie support fix works
Ran tests against HBase 2.2.7 and Phoenix 5.2.0-SNAPSHOT which all
passed (except those tests which expect no extra tables present).
On 5/14/21 3:46 PM, Istvan Toth wrote:
Hello
+1 (binding)
* Can build from src
* xsums/sigs are good
* KEYS is up-to-date
* Unit tests all passed!
I think ASF guidelines want the commit ID (not just a tag) in a VOTE
email, but let's just use that for future guidance. The git-tag of
0.1.6.1RC1 points to
Josh Elser created PHOENIX-6463:
---
Summary: PQS jar hosting doesn't include pom's
Key: PHOENIX-6463
URL: https://issues.apache.org/jira/browse/PHOENIX-6463
Project: Phoenix
Issue Type: Bug
No objections over here! Y'all already know the work Istvan and Richard
have been doing to push on Phoenix 5.1. That continues to be our focus.
On 5/7/21 11:13 AM, Viraj Jasani wrote:
Hi,
Based on HBase community's decision to EOL branch-1 after 1.7.0 release as
per the discussion thread [1],
[
https://issues.apache.org/jira/browse/PHOENIX-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-6459.
-
Resolution: Fixed
> phoenixdb ignores cookies set by the ser
[
https://issues.apache.org/jira/browse/PHOENIX-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-6459:
Fix Version/s: python-phoenixdb-1.0.1
> phoenixdb ignores cookies set by the ser
Yes, that'd be great.
The tl;dr for others: Knox employs a cookie for redirecting clients back
to the same backend PQS server. However, the Python library didn't pass
this cookie back to Knox. This results in the second Avatica API call
going to a different PQS instance which doesn't have the
Josh Elser created PHOENIX-6459:
---
Summary: phoenixdb ignores cookies set by the server
Key: PHOENIX-6459
URL: https://issues.apache.org/jira/browse/PHOENIX-6459
Project: Phoenix
Issue Type
o interested in solving this
problem,
Let me know how I can help?
Thanks
Jacob
On Wed, Apr 7, 2021 at 9:05 AM Josh Elser wrote:
Thanks for trying to tackle this sticky problem, Istvan. For the context
of everyone else, the real-life problem Istvan is trying to fix is that
you cann
All points look good to me :)
On 4/19/21 4:31 AM, Istvan Toth wrote:
Hi!
Due to low interest, Tephra support tends to be broken on master (and in
this case, on recent releases).
The current problems with Tephra integration are described in PHOENIX-6442.
However, before we can fix that, we
Thanks for trying to tackle this sticky problem, Istvan. For the context
of everyone else, the real-life problem Istvan is trying to fix is that
you cannot run a Spark application with both HBase and Phoenix jars on
the classpath.
If I understand this correctly, it's that the HBase API
think just that could take more than 15 minutes. :)
On Thursday, March 18, 2021, 9:18:40 AM PDT, Josh Elser
wrote:
What I think we have now is..
* 15mins Hue
* 15mins on PQS and Python
I think a full hour might be too much, depends on amount of Q
On 3/17/21 6:24 PM, Kadir Ozdemir wrote
Sounds good. I'll work with folks internally to put together an agenda.
On 3/19/21 2:11 PM, Kadir Ozdemir wrote:
Thank you for volunteering for the April meeting. You are the host for it.
It will be great if you can write a brief abstract/description about the
meeting topic that I can send out
integration with Hue. Do you suggest to
discuss all in one meeting?
Thanks,
Kadir
On Wed, Mar 17, 2021 at 2:26 PM Josh Elser wrote:
While we try to figure out who will give it, I think I am safe to say we
can offer a discussion on PQS, the Phoenix Python library, and its
integration with Hue [1
[
https://issues.apache.org/jira/browse/PHOENIX-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-6414:
Description:
When connecting to Phoenix from Python using "SPNEGO" as the auth
While we try to figure out who will give it, I think I am safe to say we
can offer a discussion on PQS, the Phoenix Python library, and its
integration with Hue [1].
Is this of interest?
[1] https://gethue.com/
On 3/9/21 1:54 PM, Kadir Ozdemir wrote:
Hi All,
This is a friendly reminder
Be sure to update
https://dist.apache.org/repos/dist/release/phoenix/KEYS with your key
prior to releasing this.
+1 (binding)
* Sigs/xsums are good
* No unexpected files in source release
* rat:check passes
* Build from src, ran against 1.4.13
On 2/16/21 12:08 AM, Xinyi Yan wrote:
Hello
Love it! I'll do my best to join in and listen (and participate later
on, too ;))
I joined one from Calcite a week or two ago. They did a signup via
Meetup.com and hosted it through Zoom. It felt very professional.
On 2/4/21 12:10 PM, Kadir Ozdemir wrote:
We are very excited to propose an
I'd request that we keep hbase-2.2 support around for a while longer. If
we drop that, it's going to cause us some major headache whereas I'd
rather see us able to keep pushing our dayjob efforts directly into
upstream.
On 1/28/21 11:56 PM, Viraj Jasani wrote:
+1(non-binding) to EOLing the
IMO, a slow build is better than forcing users to run their own dev
build of a release.
Very proud of all of the work y'all have been doing on 4.16. Keep
pushing on the release :)
On 1/12/21 12:35 PM, Istvan Toth wrote:
I've been working this, and came up with the following:
* We no longer
+1 (binding)
* xsums/sigs OK
* CHANGES has reasonable content
* mvn apache-rat:check passes and `find . -type f` doesn't show anything
unreasonable
* Can build the code
* Ran many unit tests, but cancelled at ~1hr mark.
* Can build Phoenix master against 0.16.0rc2
On 11/30/20 8:15 AM, Istvan
Should we just incorporate the omid and tephra websites into phoenix.a.o
going forward?
I'm surprised infra didn't kill the old websites when the IPMC
"graduated" them.
ASF websites are either updated via svn pub-sub, git pub-sub, or via ASF
CMS (which might be EOL, I forget).
svn/git
(Because I accidentally sent just to Istvan the first time)
On 11/19/20 3:27 PM, Josh Elser wrote:
+1 binding
* NOTICE has out of date copyright year. Fix for later. License appears
fine (some copyright retained by Yahoo on some benchmark files, it
seems, but still apache licensed)
* xsums
(-to: dev@phoenix, +bcc: dev@phoenix, +to: user@phoenix)
I've taken the liberty of moving this over to the user list.
Typically, such an exception is related to Kerberos authentication, when
the HBase service denies in an incoming, non-authenticated client.
However, since you're running
Sounds good to me. Yes, would say that private SVN space is good.
I can't find any existing private space, so I think it would be an ask
to infra, e.g. https://issues.apache.org/jira/browse/INFRA-15461
On 10/21/20 1:23 AM, Istvan Toth wrote:
Hi!
I've recently implemented the Yetus PR
+1 (binding)
* L seem fine
* RELEASENOTES.md is empty, maybe we'll have content in there later?
(Mentioning in case there should have been content)
* phoenix-shaded-guava jar looks sane
* apache-rat:check passes
* Nice content in CHANGES.md
* Built phoenix.git with this release
On 10/14/20
Sounds reasonable to me.
We have the same kind of thing going since phoenix-queryserver was moved
out to its own repository. Maybe we can come up with some conventions as
to how we "overlay" things so that Omid, PQS, and Tephra can all have
some semblance of familiarity?
I think that would
+1 (binding)
* Xsums/sigs are good
* dist/dev/phoenix/KEYS was updated but dist/release/phoenix is the
official KEYS file that you need to add your key to, Istvan
* dev-support's RAT check passed
* No unexpected files in the source release
* Was able to run tests against all Python versions in
[
https://issues.apache.org/jira/browse/PHOENIX-5881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-5881:
Attachment: PHOENIX-5881.v4.patch
> Port MaxLookbackAge logic to
[
https://issues.apache.org/jira/browse/PHOENIX-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-6084.
-
Resolution: Invalid
It seems like your complaint is that the _Guava_ code {{InternetDomainName
[
https://issues.apache.org/jira/browse/PHOENIX-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-6068:
Priority: Blocker (was: Major)
> (5.x) Read repair reduces the number of rows retur
[
https://issues.apache.org/jira/browse/PHOENIX-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned PHOENIX-6068:
---
Assignee: (was: Kadir OZDEMIR)
> (5.x) Read repair reduces the number of r
[
https://issues.apache.org/jira/browse/PHOENIX-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-6068:
Fix Version/s: (was: 4.16.0)
5.1.0
> (5.x) Read repair reduces the num
Josh Elser created PHOENIX-6068:
---
Summary: (5.x) Read repair reduces the number of rows returned for
LIMIT queries
Key: PHOENIX-6068
URL: https://issues.apache.org/jira/browse/PHOENIX-6068
Project
[
https://issues.apache.org/jira/browse/PHOENIX-6067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-6067:
Priority: Blocker (was: Major)
> (5.x) IndexTool's inline verification should not verify r
[
https://issues.apache.org/jira/browse/PHOENIX-6067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-6067:
Fix Version/s: (was: 4.15.1)
5.1.0
> (5.x) IndexTool's inl
[
https://issues.apache.org/jira/browse/PHOENIX-6067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned PHOENIX-6067:
---
Assignee: (was: Weiming Wang)
> (5.x) IndexTool's inline verification sho
Agreed with Istvan on the importance of the new secondary indexing.
Thanks for the super-clear list, Geoffrey. I'll spin out clones of each
of the BLOCKERs you mention and tag them for 5.1.0 (not that they get lost).
Thanks you, Istvan, for your very thoughtful write-up. Looks like a
great
Josh Elser created PHOENIX-6067:
---
Summary: (5.x) IndexTool's inline verification should not verify
rows beyond max lookback age
Key: PHOENIX-6067
URL: https://issues.apache.org/jira/browse/PHOENIX-6067
+1 Looks like a good plan, and happy to see PR's up for it already :)
On 7/16/20 8:44 AM, rajeshb...@apache.org wrote:
Sounds like a good plan and good work Istvan! Having pre-shaded third party
repo and using in most of the dependent components like Omid, Tephra avoids
a lot of headaches with
Josh Elser created PHOENIX-5999:
---
Summary: Have executemany leverage ExecuteBatchRequest
Key: PHOENIX-5999
URL: https://issues.apache.org/jira/browse/PHOENIX-5999
Project: Phoenix
Issue Type
[
https://issues.apache.org/jira/browse/PHOENIX-5778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-5778.
-
Resolution: Fixed
Thanks, Guanghao! Sorry again for the delay in applying this. Always good
[
https://issues.apache.org/jira/browse/PHOENIX-5778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-5778:
Component/s: queryserver
> Remove the dependency of KeyStoreTestU
[
https://issues.apache.org/jira/browse/PHOENIX-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-4844:
Fix Version/s: (was: queryserver-1.0.0)
> Refactor queryserver tests to
[
https://issues.apache.org/jira/browse/PHOENIX-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-4844:
Component/s: queryserver
> Refactor queryserver tests to use QueryServerTestU
[
https://issues.apache.org/jira/browse/PHOENIX-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-5901.
-
Fix Version/s: queryserver-1.0.0
Resolution: Fixed
> Add LICENSE and NOTICE fi
Thanks Chenglei!!
On 6/21/20 12:00 PM, cheng...@apache.org wrote:
I observed that when the ITtests hange, the ZK connection exhaustion is caused
by ViewUtil.dropChildViews , and I opened a JIRA PHOENIX-5970 to solve it,
seems that it works.
At 2020-06-19 14:58:27, "Istvan
Josh Elser created PHOENIX-5967:
---
Summary: phoenix-client transitively pulling in phoenix-core
Key: PHOENIX-5967
URL: https://issues.apache.org/jira/browse/PHOENIX-5967
Project: Phoenix
Issue
Fine by me. I think keeping `phoenix-queryserver-client` the same is the
one that's most important. However, since the move to the separate repo
and that we've not had a real release from it yet, we have the
flexibility to make the change now.
On 6/19/20 3:31 AM, Istvan Toth wrote:
Hi!
I'd
/PHOENIX-5828 is
quite similar to it.
On Wed, Jun 17, 2020 at 2:49 AM Guanghao Zhang wrote:
HBase 2.0 and 2.1 has been EOL now. Does phoenix need to support them?
swaroopa kadam 于2020年6月17日周三 上午12:32写道：
yes, that’s a good idea.
On Tue, Jun 16, 2020 at 9:29 AM Josh Elser wrote:
Sounds like we
Josh Elser created PHOENIX-5966:
---
Summary: Include poms in embedded maven repo
Key: PHOENIX-5966
URL: https://issues.apache.org/jira/browse/PHOENIX-5966
Project: Phoenix
Issue Type
[
https://issues.apache.org/jira/browse/PHOENIX-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned PHOENIX-5901:
---
Assignee: Josh Elser (was: Istvan Toth)
> Add LICENSE and NOTICE files to phoe
Sounds like we should try to update precommit to at least compile
against _a version_ in each line 2.1/2.2/2.3 for master. Thoughts?
On 6/16/20 11:57 AM, swaroopa kadam wrote:
Thank you for the replies everyone!
It puts me at ease by knowing the issue has been identified and being
fixed.
- Testing the release process /making RC releases on TestPyPI
One more detail that we haven't discussed yet:
The previous PyPI releases were source packages.
I suggest that we can keep releasing PhoenixDB as a source package, as it
is pure python.
Istvan
On Tue, Jun 16, 2020 at 3:32 AM Josh E
n 15, 2020 at 7:08 PM Josh Elser wrote:
Did a little searching..
* Found a 2011 blog post from sqlalchemy which said (as a project) they
would not post devN releases to pypi
* There's a TestPyPi [1] instead which seems to be for staging work.
Could we play with staging there? And then push to
One more thing :)
Apache Beam appears to have an excellent release guide which includes
their process which involves PyPi --
https://beam.apache.org/contribute/release-guide/
Maybe we can copy them?
On 6/15/20 1:08 PM, Josh Elser wrote:
Did a little searching..
* Found a 2011 blog post
?
I think we can keep our python release super-low friction :)
[1] https://packaging.python.org/guides/using-testpypi/
On 6/15/20 1:02 PM, Josh Elser wrote:
Hey Istvan,
Great of you to drive this work!
I do have one concern about pushing the dev releases to PyPi (I'm
assuming that's what you
Hey Istvan,
Great of you to drive this work!
I do have one concern about pushing the dev releases to PyPi (I'm
assuming that's what you mean). I understand that in the Python world a
"dev" release indicates that this isn't an "official" release [1].
At the ASF, you're correct that we,
[
https://issues.apache.org/jira/browse/PHOENIX-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-5939:
Summary: Publish PhoenixDB to PyPI (was: Plublish PhoenixDB to PyPI)
> Publish Phoeni
Hiya,
Richard (and Istvan) had a chat with me the other day about the change
Richard has started making here.
Given what I know so far, I think Richard is trying to fix a
long-standing "it just is that way"-ism from Phoenix.
Please give it a glance and make sure we're working towards a
Sounds like a well-thought-out plan to me.
If we're going through and changing Guava, it may also be worthwhile to
try to eliminate the use of Guava in our "public API". While the shaded
guava eliminates classpath compatibility issues, Guava could (at any
point) drop a class that we're using
[
https://issues.apache.org/jira/browse/PHOENIX-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reopened PHOENIX-5922:
-
This breaks compilation on master: there are two StringUtils imports and
redefines
[
https://issues.apache.org/jira/browse/PHOENIX-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned PHOENIX-5831:
---
Assignee: Richard Antal
> Make Phoenix queryserver scripts work with Pytho
[
https://issues.apache.org/jira/browse/PHOENIX-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned PHOENIX-5656:
---
Assignee: Richard Antal
> Make Phoenix scripts work with Pytho
Josh Elser created PHOENIX-5869:
---
Summary: Use symlinks to reduce size of phoenix queryserver
assembly
Key: PHOENIX-5869
URL: https://issues.apache.org/jira/browse/PHOENIX-5869
Project: Phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-5827.
-
Resolution: Fixed
Thanks for your reviews, Istvan!
> Let PQS act as a maven r
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 the responsibilities of the VP to be largely oversight
and secretarial. That is, a VP should be
Josh Elser created PHOENIX-5827:
---
Summary: Let PQS act as a maven repo
Key: PHOENIX-5827
URL: https://issues.apache.org/jira/browse/PHOENIX-5827
Project: Phoenix
Issue Type: Improvement
Going to start working on this for PQS. It will be behind a feature-flag
that folks would have to opt-in to.
On 4/7/20 4:47 PM, Josh Elser wrote:
Hi,
Over in HBASE-24066, I had hacked together a POC which shows the HBase
UI hosting shaded client jars for Maven-based users. Nick had raised
It looks like the Phoenix-Master[1] build is now defunct after Istvan's
hbase profile work. New job over in [2] which is a matrix job for all of
HBase 2.0, 2.1, and 2.2.
I think the question is whether or not we want to keep the old job
around? I think the answer is "no".
[1]
Josh Elser created PHOENIX-5823:
---
Summary: Clean up phoenix-client vestiges from a non-attached jar
Key: PHOENIX-5823
URL: https://issues.apache.org/jira/browse/PHOENIX-5823
Project: Phoenix
Hi,
Over in HBASE-24066, I had hacked together a POC which shows the HBase
UI hosting shaded client jars for Maven-based users. Nick had raised
some concerns about inadvertently impacting the HBase Master, so it's
stalled out at this point.
https://issues.apache.org/jira/browse/HBASE-24066
[
https://issues.apache.org/jira/browse/PHOENIX-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-5146.
-
Resolution: Incomplete
No clear problem and reproduction can be provided. User list
On 3/26/20 5:22 AM, Istvan Toth wrote:
On Thu, Mar 26, 2020 at 5:39 AM Guanghao Zhang wrote:
I thought user still need to care about which hbase version in use?
phoenix-server-xxx-hbase-2.1.jar not worked with hbase 2.2.x cluster now?
They do need to care when they are referencing maven
Background: IstvanT has done a lot of really great work to clean up the
HBase 2.x compatibility issues for us. This lets us move away from the
HBase-version-tagged releases of Phoenix (e.g. HBase-1.3, HBase-1.4,
etc), and keep a single branch which can build all of these.
Building master
[
https://issues.apache.org/jira/browse/PHOENIX-5778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned PHOENIX-5778:
---
Assignee: Guanghao Zhang
> Remove the dependency of KeyStoreTestU
table by maven profile would
either require lots of developer copy/paste for each change, or a
significant (probably long overdue) refactor to make the coprocs
small
shims that call out to smaller, fine-grained classes that can
occasionally
be release-specific.
Geoffrey
On Fri, Feb 7,
[
https://issues.apache.org/jira/browse/PHOENIX-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned PHOENIX-5699:
---
Assignee: Richard Antal
> Investigate reducing chore intervals in MiniCluster to speed
ver-year but the dev and issues list have an increase of a similar
percentage magnitude year-over-year. In general, I observe a steady
stream of
user questions and developers created and resolving Jira issues.
On 2/6/20 8:11 PM, Josh Elser wrote:
Yo,
It's that time which is so nice, it comes four
Congratulations and welcome, Gokcen!
On 2/10/20 1:55 PM, 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 bug fixes as part
Sounds like a good idea to me.
On 2/6/20 8:40 AM, Istvan Toth wrote:
Hello!
Now that we have a working solution in master for handling different HBase
minor versions, I think that we should think about applying the same
template to 4.x., and unifying the 4.x-HBase-1.3, 1.4, and 1.5 branches.
Yo,
It's that time which is so nice, it comes four times a year: board
report time!
Things that are jumping out at me:
* Omid & Tephra "adoption"
* 4.15.0 released
* HBase2 compat stuff landed to unblock next 5.x release
Please tell me what else you think is worth mentioning.
If you forgot
If you are the release manager for Phoenix, make sure you are adding the
new release here as a final step:
https://reporter.apache.org/addrelease.html?phoenix
This is important in that it gives folks (e.g. ASF members and ASF board
members) insight into the releases we're doing. It looks like
Thanks for sending out the reminder, Istvan!
Those interested: please take a look ASAP or give a shout for more time
to review. On it's current trajectory, I think the PR will be in a place
to merge tomorrow (2020/02/05, US times).
On 1/30/20 2:49 PM, Istvan Toth wrote:
I have received a
[
https://issues.apache.org/jira/browse/PHOENIX-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-5693.
-
Fix Version/s: (was: connectors-1.0.0)
(was: 4.15.0
[
https://issues.apache.org/jira/browse/PHOENIX-5687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved PHOENIX-5687.
-
Resolution: Later
> Phoenix-client-5.0.0 can not run on jd
[
https://issues.apache.org/jira/browse/PHOENIX-5683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-5683:
Description:
Multiple warnings/error from Maven as to the pom structure for the project
1 - 100 of 1733 matches
Mail list logo
