ve +1 vote, but mine
would be non-binding one.
Awaiting one more PMC binding vote.
On Fri, 4 Jun 2021 at 11:59 PM, la...@apache.org wrote:
> So are we good?
>
> Assuming Viraj's +1 is implied we have three +1 and not -1.
>
> -- Lars
>
>
> On Wednesday, June 2, 2021, 7:
So are we good?
Assuming Viraj's +1 is implied we have three +1 and not -1.
-- Lars
On Wednesday, June 2, 2021, 7:10:58 AM PDT, Istvan Toth
wrote:
+1 (binding)
Checksum for source distribution: OK
Signature for source distribution: OK
Release notes and changes files look good: OK
mvn c
+1 (binding)
Built from source, ran a local HDFS/ZK/HBase/Phoenix stack, inserted 26m rows,
created some indexes, queried, tried the Trino-Phoenix connector.
All checks out.
-- Lars
On Monday, May 31, 2021, 12:01:07 AM PDT, Viraj Jasani
wrote:
Please vote on this Apache phoenix rele
Exception at times. Not much
> sure about AuditLoggingIT though.
>
> Pherf test fails with HBase 2.1.
>
>
> On Fri, 28 May 2021 at 10:44 PM, la...@apache.org
> wrote:
>
>> 5.1 CI builds seems to fail consistently - at least for the past two
>> weeks.
>>
>&g
d, 26 May 2021 at 11:53 PM, la...@apache.org wrote:
> I cherry-picked three changes into branch 5.1.
> Assuming Jira is up-to-date, there are no 4.16.x issues that are not also
> in 5.1.x.
>
> There are 12 issues left that are in 4.17.0 and 5.2.0, but not in 5.1.x.
> But they are p
ded is great, so I'd lean towards #2.
>
> We can see what adoption of phoenix-client-embedded looks like now that
> we have it in releases. I imagine most folks haven't yet realized that
> it's even an option that's available.
>
> On 5/26/21 1:16 PM, la...@
- if so - should not be in 5.1.2.
-- Lars
On Wednesday, May 26, 2021, 10:15:31 AM PDT, la...@apache.org
wrote:
Awesome. Thanks Istvan.
I'll do a pass through the issues too.
-- Lars
On Tuesday, May 25, 2021, 8:45:00 PM PDT, Istvan Toth wrote:
I am not aware of any blockers i
Will sqlline still be part of the Phoenix "distribution"? Or will it become a
separate package to install?
On Wednesday, May 26, 2021, 1:07:17 AM PDT, Istvan Toth
wrote:
Hi!
The current purpose of the phoenix-client JAR is twofold:
- It servers as a generic JDBC driver for embedding
y.
I will also look for missing fixes before release, but if anyone is aware
of any fix that is needed in 5.1.2 , but
hasn't been backported, then please try to get it resolved by Monday.
regards
Istvan
On Wed, May 26, 2021 at 4:19 AM la...@apache.org wrote:
> There are 17 resolved issu
There are 17 resolved issues against it.
PHOENIX-6436 is needed for further integration with Trino (formerly Presto).
It is time for another point release?
-- Lars
d hence can't go out in 4.16.2 or 5.1.2. (See PHOENIX-6247
> -- which should be marked Resolved -- and PHOENIX-6457).
>
> Do we need the dual maintenance of a 5.1 patch branch?
>
> Geoffrey
>
> On Wed, May 12, 2021 at 12:55 PM la...@apache.org
> wrote:
>
> > Hi
Hi all,
I noticed some changes that went into both master and the 4.x branch, but not
into branch-5.1.
Unfortunately I do not have time to check each edit.
When you commit changes, please do not forget about branch-5.1, which will
produce our next version of Phoenix.
Cheers.
-- Lars
There is also another angle to look at. A long time ago I wrote this:
"
It seems Phoenix serves 4 distinct purposes:
1. Query parsing and compiling.
2. A type system
3. Query execution
4. Efficient HBase interface
Each of these is useful by itself, but we do not expose these as stable
interfaces
Please comment on the Jira if you have an opinion :)
On Monday, March 29, 2021, 10:48:34 AM PDT, la...@apache.org
wrote:
Filed https://issues.apache.org/jira/browse/PHOENIX-6433
We can discuss there.
In the end, IMHO, placing columns in distinct column families is a physical
column features are not
affected.
We may or may not want to add a property to override it (with the
default being disallowing the duplicate column names)
Istvan
On Sat, Mar 27, 2021 at 5:59 PM la...@apache.org wrote:
> Viraj, yeah similar discussion.
>
> Istvan, good point. Of course y
gt; aliasing the columns may solve that)
> Another thing to consider is how this would affect dynamic column use cases
> for either native Phoenix tables of views on HBase tables.
>
> Istvan
>
> On Sat, Mar 27, 2021 at 12:20 AM la...@apache.org
> wrote:
>
> > As yo
As you may or may not know, Phoenix allows for duplicate column names as long
as they are placed in different column families.
You can create a table such as CREATE TABLE t (pk1 ..., x.v1, y.v1, ...).
Now each time you want to refer to v1 you need to qualify it with its column
family or you get
leave the decision to the PMC.
We have two binding +2s at the moment, so I'll just follow procedure, and
make the decision based on the next binding vote.
Istvan
On Sat, Mar 20, 2021 at 7:30 PM la...@apache.org wrote:
> PHOENIX-6423 could be blocker...?
>
> What happens is that SEL
M PDT, la...@apache.org
wrote:
If 5.1.1 is sunk for any reason, I'd like to get PHOENIX-6421 in. (By itself
it's not enough to sink the release, I think)
On Wednesday, March 17, 2021, 8:53:59 PM PDT, Xinyi Yan
wrote:
+1 (non-binding)
Besides the signature, checksum,
If 5.1.1 is sunk for any reason, I'd like to get PHOENIX-6421 in. (By itself
it's not enough to sink the release, I think)
On Wednesday, March 17, 2021, 8:53:59 PM PDT, Xinyi Yan
wrote:
+1 (non-binding)
Besides the signature, checksum, and mvn install/verify, I built from the
source and
An interesting topic would BigData ecosystem integration, which is clearly one
of the strengths of Phoenix.
I.e. with Trino (formerly Presto), Spark, and classical MapReduce. Perhaps this
could cover also HBase snapshot support.
I'm happy to cover this. But I can't to that for April 1st - juggl
In addition to the technical implementation of the PQS an interesting topic for
the PQS would be how to scale it.
How many PQSs compared to the number of region servers? How to size the
machine/VM? Etc.
I think just that could take more than 15 minutes. :)
On Thursday, March 18, 2021, 9:18:40 AM
>
> at org.junit.Assert.assertEquals(Assert.java:117)
>
> at
> org.apache.phoenix.end2end.ViewTTLIT.verifyRowsBeforeTTLExpiration(ViewTTLIT.java:2462)
>
> at
> org.apache.phoenix.end2end.ViewTTLIT.validateExpiredRowsAreNotReturnedUsingData(ViewTTLIT.java:2390)
>
> at
> org.apache.phoenix.end2end.ViewTTLIT.upsertDataAndRunVa
+1 (binding)
Built from source, ran some test loads with a few million rows on a local
install.
Ran some choice tests.
Nothing weird in the logs.
-- Lars
On Tuesday, March 16, 2021, 8:28:43 AM PDT, Istvan Toth
wrote:
Please vote on this Apache phoenix release candidate,
phoenix-5.1.
Just came here to say the same.
While we're at it, let's also pull in PHOENIX-6409, as it bring better
visibility into local index plans.
-- Lars
On Thursday, March 11, 2021, 11:41:52 PM PST, Viraj Jasani
wrote:
Thanks Istvan.
I believe we can get in PHOENIX-6385 with 5.1.1 since it is
I just committed PHOENIX-6402
Let's have another attempt at an RC for 5.1.1.
(Assuming all tests continue to pass)
-- Lars
On Sunday, March 7, 2021, 3:30:46 PM PST, la...@apache.org
wrote:
I have a real fix ready in PHOENIX-6402. Let's wait for that and then do a
5.1
I have a real fix ready in PHOENIX-6402. Let's wait for that and then do a
5.1.1 release.
On Monday, March 1, 2021, 4:15:40 PM PST, la...@apache.org
wrote:
-1 (binding)
See https://issues.apache.org/jira/browse/PHOENIX-6400
I'm testing a bit more, but that looks wrong
On 2021/03/02 02:03:03, "la...@apache.org" wrote:
> AHA...
> Looks like hadoop-ci is failing with the same exception, since Feb 18th,
> looks like PHOENIX-6359 is the culprit.
>
> So it's not me.
>
>
> On Monday, March 1, 2021, 5:46:51 PM PST, la...@apa
AHA...
Looks like hadoop-ci is failing with the same exception, since Feb 18th, looks
like PHOENIX-6359 is the culprit.
So it's not me.
On Monday, March 1, 2021, 5:46:51 PM PST, la...@apache.org
wrote:
My apologies if this is dumb question - I've been working on other proje
My apologies if this is dumb question - I've been working on other projects for
a while, now coming back to some Phoenix work.
I'm trying to simply run mvn test -Dtest=LocalIndexIT locally.
And the test always fails with:
[ERROR] org.apache.phoenix.end2end.index.LocalIndexIT Time elapsed: 39.41
-1 (binding)
See https://issues.apache.org/jira/browse/PHOENIX-6400
I'm testing a bit more, but that looks wrong.
-- Lars
On Sunday, February 28, 2021, 7:32:09 PM PST, Xinyi Yan
wrote:
+1 (non-binding) based on the signature, checksum and mvn clean
install/verify.
On Sun, Feb 28, 202
Actually it was relatively easy to work around PHOENIX-6377 - at least with
Trino (formerly Presto) where we discovered the problem in the first place.
That said, I'll hold off Phoenix 5.x support for Trino until after Phoenix
5.1.1 as long as we can get a release out soon'ish.
On Sunday, Febr
FWIW, I agree.
As I'm experiencing with the Trino (formerly Presto) Phoenix connector, it is
hard as is to support different versions of Phoenix (and HBase)...
To the point where I'm adding a second Phoenix connector to Trino just for
Phoenix 5.1.0+ support (and Phoenix 5.0 cannot be supported a
Geoffrey did the forward port for consistent indexes.
I'll add PHOENIX-5712 to the list of blockers - we've gotten ourselves into a
bind there with backwards compatibility,
and there's still not clear fix in sight as far as I can see. That same problem
exists for4.16.
On the HBase front all inn
Hi All,
I won't have time to go through various tests again to speed them up as I did
last year.
Instead let me at least publicly shame the slowest tests that take more than 10
minutes to run:
1,620.111 org.apache.phoenix.end2end.InListIT
1,486.974 org.apache.phoenix.end2end.ParameterizedIndex
Thanks Istvan.
Just checked the builds. Looks like the 4.x builds have not passed a single
time since May 20th.
I hope I am missing something... Otherwise this would be pretty frustrating. :)
(Since pleading doesn't appear to help, maybe we should automatically block all
commits until all tests
ppropriate 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 exception I'm seeing.
>
> 2020-05-15 15:35:36,098 FATAL [RS_OPEN_PRIORITY_REGION-think:16201-1]
>
I can fix that by copying phoenix-hbase-compat-1.5.0-4.16.0-SNAPSHOT.jar from
phoenix/lib to hbase/lib.
That is not intended I assume. There used to be just the Phoenix server jar
needed.
On Friday, May 15, 2020, 3:55:32 PM PDT, la...@apache.org
wrote:
PHOENIX-5808 looks suspicious (I
PHOENIX-5808 looks suspicious (I do like the change, it just may introduce this
problem)
On Friday, May 15, 2020, 3:48:02 PM PDT, la...@apache.org
wrote:
This is the exception I'm seeing.
2020-05-15 15:35:36,098 FATAL [RS_OPEN_PRIORITY_REGION-think:16201-1]
regionserver.HRegionS
This is the exception I'm seeing.
2020-05-15 15:35:36,098 FATAL [RS_OPEN_PRIORITY_REGION-think:16201-1]
regionserver.HRegionServer: ABORTING region server think,16201,1589581955446:
The coprocessor org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver
threw java.lang.NoClassDefFoundEr
.apache.org/view/M-R/view/Phoenix/job/PhoenixFindTestTimeout/
though I haven't looked into the last one.
István
On Thu, Apr 9, 2020 at 1:30 AM la...@apache.org wrote:
> Thanks Josh.
>
> unfortunately
>
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matr
/Phoenix-master/
[2]
https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matrix/
On 4/8/20 2:00 PM, la...@apache.org wrote:
> Just looking at the Phoenix Jenkins jobs I noticed that was no build on
> master since for 3 weeks.
> Is that in purpose? There were clearly chan
Just looking at the Phoenix Jenkins jobs I noticed that was no build on master
since for 3 weeks.
Is that in purpose? There were clearly changes on the master branch since then.
Cheers.
-- Lars
lways* passing. It's impossible to maintain a stable
code base the size of Phoenix otherwise.
-- Lars
On Tuesday, January 14, 2020, 10:04:12 AM PST, la...@apache.org
wrote:
I spent a lot of time making QA better. It can be better, but it's stable
enough. There're now
st too frustrating and
> error-prone.
>
> It would also be great if we could have a single Phoenix jar that works
> across HBase versions, but would not die on that hill :)
>
> On 12/20/19 5:04 AM, la...@apache.org wrote:
> > I said _provided_ they can be isolated easily
eople will presumably start to care. :)If I hear
no objects I'll start doing that a while.
Cheers.
-- Lars
On Monday, January 13, 2020, 06:23:01 PM PST, Josh Elser
wrote:
How do we keep getting into this mess: unreliable QA, people ignoring
QA, or something else?
On 1/12/20 9:24 PM
... Not much else to say here...
The tests have been failing again for a while... I will NOT fix them again this
time! Sorry folks.
-- Lars
ndier than bash but sometimes the
> right tool for the job is the right tool for the job. Unlike python, bash
> has a very stable grammar.
>
> On Thu, Jan 9, 2020 at 12:34 PM la...@apache.org wrote:
>
>> Hi all,
>>
>> python2 is officially EOL'd. No more changes,
Hi all,
python2 is officially EOL'd. No more changes, improvements, or fixes will be
done by the developers.
Some Linux distributions stopped shipping Python2.
It turns out our scripts do not work with Python3, see: [PHOENIX-5656] Make
Phoenix scripts work with Python 3 - ASF JIRA.
[PHOENIX-56
en 1 and
2 is good enough for normal client operations. If the version check didn’t
throw an exception I wonder if there would be any issue.
For your consideration.
> On Dec 21, 2019, at 2:40 AM, "la...@apache.org" wrote:
>
> Yeah! Finally.
> Let's use this time
Yeah! Finally.
Let's use this time to stabilize; especially the metadata management and
upgrade testing (and perhaps the HBase compatibility), so that we can have a
smooth 4.16.0 release.
On Saturday, December 21, 2019, 1:19:34 AM GMT+1, Chinmay Kulkarni
wrote:
Hello Everyone,
The A
herit HBase classes or implement
> HBase interfaces, and those can vary between minor versions. (See my above
> example of a new coprocessor hook on BaseRegionObserver.)
>
> Geoffrey
>
> On Thu, Dec 19, 2019 at 10:54 AM la...@apache.org
> wrote:
>
> > Yep. The d
rit HBase classes or implement
HBase interfaces, and those can vary between minor versions. (See my above
example of a new coprocessor hook on BaseRegionObserver.)
Geoffrey
On Thu, Dec 19, 2019 at 10:54 AM la...@apache.org wrote:
> Yep. The differences are pretty minimal - provided they can be isol
Elser
wrote:
To clarify, you think that compat modules are better than that
separate-branches model in 4.x?
On 12/18/19 11:29 AM, la...@apache.org wrote:
> This is really hard to follow.
>
> I think we should do the same with HBase dependencies in Phoenix that HBase
> does
This is really hard to follow.
I think we should do the same with HBase dependencies in Phoenix that HBase
does with Hadoop dependencies.
That is: We could have a maven module with the specific HBase version
dependent code.
Btw. Tephra does the same... A module for HBase version specific code.
You mean you see multiple rows with the same primary key? I have not see this
- or heard about this before.
Could you post your schema?
-- Lars
On Tuesday, December 17, 2019, 7:42:13 PM GMT+1, Francesco Malerba
wrote:
Hi all,
we are having some troubles with Phoenix 4.14 on top of H
+1 (binding)
Again... This time I did the following:
- Ran through upgrade and various test scripts using phoenix_sandbox.py (with
PHOENIX-5617 applied). This started with 4.14, created some tables, views, and
indexes, then with a 4.15 client, added/removed views, columns, and indexes,
then wit
PMC, please test and vote on this :)
On Monday, December 9, 2019, 4:43:02 PM PST, la...@apache.org
wrote:
+1 (Binding)
Did the same tests as in RC2. :)
Cheers and crossing fingers.
-- Lars
On Monday, December 9, 2019, 02:48:41 PM PST, Chinmay Kulkarni
wrote:
Hello
at, Dec 7, 2019 at 10:39 AM la...@apache.org wrote:
> I filed a blocker bug for 4.16.0 to improve backward compatibility and
> tests for the same.And I wow to veto any 4.16 release without that in
> place. We've almost reached the point at which Phoenix becomes
> unreleasable, thi
+1 (Binding)
Did the same tests as in RC2. :)
Cheers and crossing fingers.
-- Lars
On Monday, December 9, 2019, 02:48:41 PM PST, Chinmay Kulkarni
wrote:
Hello Everyone,
This is a call for a vote on Apache Phoenix 4.15.0 RC3. This is the next
minor release of Phoenix 4, compatible with
unity we seem to fail following well known
software engineering principles (always releasable code base, agile principles,
frequent releases, comprehensive test suite, etc, etc).
Cheers.
-- Lars
On Friday, December 6, 2019, 1:57:50 PM PST, la...@apache.org
wrote:
Sigh. Agreed.
I chan
reate a
> > table
> > > > > with a
> > > > > > > few indexes and ran some queries.
> > > > > > > Everything looks good.
> > > > > > >
> > > > > > > On Thu, Dec 5, 2019 at 11:35 AM C
That leads me to a general question:
(1) Will OMID and TEPHRA continue to be usable standalone without Phoenix? In
that case we should keep the OMID and TEPHRA projects in Jira.
Or (2) do we envision to tightly integrate those into the Phoenix and have them
only work in the Phoenix contexts?
+1 (binding)
I did the following:
- built from source
- verified tar ball
- ran with tip of HBase branch-1
- created tables, global and local ndexes, views, and indexes on views with
both 4.15.0 and older client
- upserted data alternately with a 4.15.0 and older client
- queried while upserting
LECT * FROM VIEW` at 4.14 client.
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Xinyi Yan
> >>>>
> >>>> On Fri, Nov 22, 2019 at 11:52 AM Neha Gupta
> >>> wrote:
> >>>>
> >>>>> +1 (Non-B
NDER - [VOTE] Release of Apache Phoenix 4.15.0 RC1*
>
> Just sending out a friendly reminder to everyone to please vote on Apache
> Phoenix 4.15.0 RC1 (thanks Lars).
>
> On Tue, Nov 19, 2019 at 2:49 PM la...@apache.org wrote:
>
>> I responded yesterday, but somehow
I responded yesterday, but somehow didn't appear to go through. Trying again...
+1 (Binding)
- built from source (4.x-HBase-1.5) with latest branch-1 HBase (also built from
source)
- loaded a few million rows
- tried with local indexes
- issued upserts and deletes while splitting in HBase.
- ch
The slightly longer answer is that HBase is very well equipped to handle this
case.Row for inner/nested relationships can be stored inline with the parent
relation, by extending the key by one more part indicating the identity of
inner rows.The trick is to teach Phoenix to understand this - suc
+1
On Wednesday, October 30, 2019, 8:27:36 AM PDT, 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 Phoenix. A
sub-project is a distinct software project from some top-level project
(TLP) bu
atibility issue.
>
> On Fri, Oct 18, 2019 at 4:25 PM la...@apache.org wrote:
>
> > Did you use one of the provided tarballs (in that case, which one)? Or
> > build from source (in that case, which branch?).
> > Also was that before or after the first 4.15 client
ropTable(MetaDataEndpointImpl.java:2153)
>
>
> On Fri, Oct 18, 2019 at 2:36 PM Chinmay Kulkarni <
> chinmayskulka...@gmail.com> wrote:
>
>> *REMINDER - [VOTE] Release of Apache Phoenix 4.15.0 RC0*
>>
>> Just sending out a friendly reminder to everyone to pleas
+1 (binding)
- Built from source
- Went through a simple 4.14 to 4.15 upgrade- Loaded a few dozens of millions
of rows.- Tried global and local indexes.- Tried HBase 1.5.0- Nothing weird in
the logs.
Looks good.
On a related note: I'd really love us to go back to a monthly release train.
That w
Seems to be happening in H35 only. Removed it from the build rotation (for
master for now)
On Thursday, July 18, 2019, 8:42:03 AM HST, la...@apache.org
wrote:
Does anybody know what could cause this? Failed at least the last 10 master
builds (which I have deleted). I'll leav
Does anybody know what could cause this? Failed at least the last 10 master
builds (which I have deleted). I'll leave one failed build up.
+1
On Monday, July 8, 2019, 12:57:27 PM HST, Thomas D'Silva
wrote:
I don't think we need to call 4.15/5.1 an alpha or beta release. Lets just
follow our usual process and release 4.15 and 5.1,
(after ensuring all the ITs pass and any manual testing that needs to be
done). If we need t
t's fine for them to go in 4.14.3.
Geoffrey
On Fri, Jun 28, 2019 at 12:20 PM la...@apache.org wrote:
> Any further comments?
> I offered to be the RM for 4.15.0, and I stand by that. I can't do it
> alone, though. Do we have consensus on the rough course of action below?
&g
ering principles, namely an
always releasable code base and small, frequent releases.
-- Lars
On Thursday, June 27, 2019, 3:07:27 PM PDT, la...@apache.org
wrote:
Thanks Geoffrey.
The damage is already done. We messed up and let it slide (multiple times, this
is by no means the first time
Hi all,
in the past weeks we had mostly successful test runs on 4.x-HBase-1.4
Yet when you look at that build it's all read. The reason is that tests all run
and finish and then Jenkins just hangs trying to archive the test artifacts for
an hour or more. That only happens on the -1.4 branch (doe
#x27;s advanced further than I know about, and we're closer
to green than I think. Happy to hear everyone's thoughts.
Geoffrey
On Thu, Jun 27, 2019 at 10:26 AM la...@apache.org wrote:
> Hi all,
> we're getting close. The test suite is passing fairly reliably now.(minus
> so
Hi all,
we're getting close. The test suite is passing fairly reliably now.(minus some
strange failure to archive the artifact in -1.4 and PartialCommitIT failing in
-1.3 only).
I put a lot of effort into speeding up the tests and making them pass. Let's
please (pretty please :) ) keep it that w
Hi all,
I'll be pushing out out a set of changes to speed up various tests.Let's see
how these go. If you see something strange, please let me know and I'll
revert/fix.
Most test runs already finish in around 2h (instead of 3h), but there're still
some bad offenders.
I'll do each test as a sepa
uld be pleased to offer my services for clean up duty. The ginsu
> I mean git knives for slicing and dicing history are sharp and at the
> ready. At the conclusion of the work you the Phoenix community will have
> only the last step to perform, which would be to resolve any lingering t
l have only the last step
to perform, which would be to resolve any lingering test issues.
> On Jun 13, 2019, at 7:29 PM, "la...@apache.org" wrote:
>
> Hi all,
> we have three active 4.x branches: 4.x-HBase-1.3, 4.x-HBase-1.4,
> 4.x-HBase-1.5.
> It looks like we&#x
Hi all,
we have three active 4.x branches: 4.x-HBase-1.3, 4.x-HBase-1.4, 4.x-HBase-1.5.
It looks like we're lacking _basic_ discipline here. There are patches in some
branches but not in others, some patches are different between these branches
for no good reason, different tests fail, etc.
I hav
t. Is this change local only for now?
https://builds.apache.org/job/PreCommit-PHOENIX-Build/
On Mon, Jun 10, 2019 at 8:54 AM la...@apache.org wrote:
> I finally managed to get a single successful test run. Yeah! :)
>
> The fact that this is worth a note to the @dev points to a larger probl
I finally managed to get a single successful test run. Yeah! :)
The fact that this is worth a note to the @dev points to a larger problem,
though... Our tests have been failing for months (or years? I don't remember
that last successful run.)
I'll continue to stabilize the tests (for 4.15.x and
+1 again based on inspection of the release artifacts.
On Thursday, May 23, 2019, 2:09:52 PM PDT, Thomas D'Silva
wrote:
Hello Everyone,
This is a call for a vote on Apache Phoenix 4.14.2 RC2. This is a patch
release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and 1.4.
The
I just inspected the artifacts. Based on that: +1
On Saturday, May 18, 2019, 12:38:47 AM PDT, Thomas D'Silva
wrote:
Hello Everyone,
This is a call for a vote on Apache Phoenix 4.14.2 RC1. This is a patch
release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and 1.4.
The rele
> The tests would take longer to run (1.3, 1.4, 1.5 and 2.x). We should
> make
> > sure our precommit build will run the tests for all the modules.
> >
> >
> >
> > On Fri, May 17, 2019 at 11:23 AM la...@apache.org
> > wrote:
> >
> > > Hi all,
>
Hi all,
historically we have a branch of each version of HBase we want to support.As a
result we have many branches, committing is a hassle and it is easy to miss a
change across branches.
Instead we could have a maven module per version of HBase we want to support
and move the version dependent
+1
On Monday, May 13, 2019, 1:31:35 PM EDT, Vincent Poon
wrote:
+1
On Sun, May 12, 2019 at 8:18 PM Andrew Purtell
wrote:
> +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
om
On Tue, Nov 13, 2018 at 11:50 PM Jaanai Zhang
wrote:
> How to connect video conference？
>
>
> Jaanai Zhang
> Best regards!
>
>
>
> la...@apache.org 于2018年11月10日周六 上午6:48写道：
>
> > To confirm:
> > Phoenix
let you up)
Thanks.
-- Lars
On Friday, November 9, 2018, 10:30:09 AM PST, la...@apache.org
wrote:
Great.
And sorry for the folks in other TZs, it's impossible to find a time for
everyone.I'll try to record the session via hangouts and post the recording
here, and I will post
Belated +1
Ran my usually tests. With upserts, deleted, global and local indexes, larger
upsert/selects, etc. Nothing undue in the logs, all works.
-- Lars
On Thursday, November 8, 2018, 3:55:07 PM PST, Vincent Poon
wrote:
The vote is now closed and passes with 4 binding +1s and no 0
ically!
Marked myself as a "M" for maybe on the spreadsheet :)
On 11/6/18 7:07 PM, la...@apache.org wrote:
> Ok. The room is booked for Wednesday November 14th from 4-7pm, in the
>Salesforce Tower (but not the top floor :( )
> If you can confirm your attendance here (see the e
would be great for planning food, etc. I will send out an agenda.
Thanks.
-- Lars
On Tuesday, October 23, 2018, 4:01:33 PM PDT, la...@apache.org
wrote:
This is still on.
I'm trying to get us a spot in the Salesforce tower top floor. As you can
imagine it's a coveted spot.If I c
er 5, 2018, 1:01:06 PM PDT, la...@apache.org
wrote:
Last call :)
On Monday, October 1, 2018, 10:15:07 AM PDT, la...@apache.org
wrote:
10 people signed up so far.This is a good chance to make your voice heard,
give input, and help point the project in the right direction going f
Last call :)
On Monday, October 1, 2018, 10:15:07 AM PDT, la...@apache.org
wrote:
10 people signed up so far.This is a good chance to make your voice heard,
give input, and help point the project in the right direction going forward.
-- Lars
On Friday, September 28, 2018, 10:39
10 people signed up so far.This is a good chance to make your voice heard,
give input, and help point the project in the right direction going forward.
-- Lars
On Friday, September 28, 2018, 10:39:41 AM PDT, la...@apache.org
wrote:
Hi all,
I'm planning to put together a Ph
Hi all,
I'm planning to put together a Phoenix developer meetup at the Salesforce
office (with video conference for those who cannot attend in person) in the
next few weeks.
If you're interested please put your name in this
spreadsheet:https://docs.google.com/spreadsheets/d/1j4QSk53B0ZIl_qq1XX3o
1 - 100 of 105 matches
Mail list logo
