See https://builds.apache.org/job/Hadoop-Common-trunk/1527/changes
Changes:
[yzhang] HDFS-8596. TestDistributedFileSystem et al tests are broken in
branch-2 due to incorrect setting of datanode attribute. Contributed by
Yongjun Zhang.
[arp] HDFS-8595. TestCommitBlockSynchronization fails in
See https://builds.apache.org/job/Hadoop-common-trunk-Java8/229/changes
Changes:
[yzhang] HDFS-8596. TestDistributedFileSystem et al tests are broken in
branch-2 due to incorrect setting of datanode attribute. Contributed by
Yongjun Zhang.
[arp] HDFS-8595. TestCommitBlockSynchronization fails
On Jun 14, 2015, at 1:00 PM, Yongjun Zhang yzh...@cloudera.com wrote:
From time to time we saw changes that work fine in trunk but not branch-2,
and we don't catch the issue in a timely manner. The difference between
trunk and branch-2 is sufficient to justify periodic jenkins test and even
I can't answer the original question but can point out the protostuff (
https://github.com/protostuff/protostuff) folks have been responsive and
friendly in the past when we (HBase) were curious about swapping in their
stuff. Two significant benefits of protostuff, IMHO, is ASL 2 licensing and
On Jun 12, 2015, at 1:03 PM, Alan Burlison alan.burli...@oracle.com wrote:
On 14/05/2015 18:41, Chris Nauroth wrote:
As a reminder though, the community probably would want to see a strong
justification for the upgrade in terms of features or performance or
something else. Right now, I'm
Anyone have a read on how the protobuf folks would feel about that? Apache
has a history of not accepting projects that are non-amicable forks.
On Mon, Jun 15, 2015 at 9:24 AM, Allen Wittenauer a...@altiscale.com wrote:
On Jun 12, 2015, at 1:03 PM, Alan Burlison alan.burli...@oracle.com
+1
(Have been talking to Sean in private on the subject -- seems
appropriate to voice some public support)
I'd be interested in this for Accumulo and Slider. For Accumulo, we've
come a far way without a pre-commit build, primarily due to a CTR
process. We have seen the repeated questions of
+1
ZooKeeper is another project that has expressed interest in improving its
pre-commit process lately. I understand Allen has had some success
applying this to the ZooKeeper build too, with some small caveats around
quirks in the build.xml that I think we can resolve.
I'm interested in
I'm clearly +1 on this idea. As part of the rewrite in Hadoop of
test-patch, it was amazing to see how far and wide this bit of code as spread.
So I see consolidating everyone's efforts as a huge win for a large number of
projects. (esp considering how many I saw suffering from a
thank you for making a more digestible version Allen. :)
If you're interested in soliciting feedback from other projects, I created
ASF short links to this thread in common-dev and hbase:
* http://s.apache.org/yetus-discuss-hadoop
* http://s.apache.org/yetus-discuss-hbase
While I agree that
Thanks Sean and Allen!
I was not aware of that there is already a way to trigger branch-2 test.
Good to know.
There are multiple solutions here:
1. When posting patches, we can post two versions of patches, one for
trunk, and one for branch-2, so to trigger two pre-commit jenkins test for
both
Sangjin Lee created HADOOP-12090:
Summary: minikdc-related unit tests fail consistently on some
platforms
Key: HADOOP-12090
URL: https://issues.apache.org/jira/browse/HADOOP-12090
Project: Hadoop
On Mon, Jun 15, 2015 at 1:39 PM, Yongjun Zhang yzh...@cloudera.com wrote:
Thanks Sean and Allen!
I was not aware of that there is already a way to trigger branch-2 test.
Good to know.
There are multiple solutions here:
1. When posting patches, we can post two versions of patches, one for
Duo Xu created HADOOP-12089:
---
Summary: StorageException complaining no lease ID when updating
FolderLastModifiedTime in WASB
Key: HADOOP-12089
URL: https://issues.apache.org/jira/browse/HADOOP-12089
On Mon, Jun 15, 2015 at 8:57 AM, Andrew Purtell apurt...@apache.org wrote:
I can't answer the original question but can point out the protostuff (
https://github.com/protostuff/protostuff) folks have been responsive and
friendly in the past when we (HBase) were curious about swapping in their
On Mon, Jun 15, 2015 at 7:24 AM, Allen Wittenauer a...@altiscale.com wrote:
On Jun 12, 2015, at 1:03 PM, Alan Burlison alan.burli...@oracle.com wrote:
On 14/05/2015 18:41, Chris Nauroth wrote:
As a reminder though, the community probably would want to see a strong
justification for the
Much like zombo.com, the only limit is yourself.
But huge Configuration objects are going to be really inefficient, so
I would look elsewhere for storing lots of data.
best,
Colin
On Fri, Jun 12, 2015 at 7:30 PM, Sitaraman Vilayannur
vrsitaramanietfli...@gmail.com wrote:
Thanks Allen, what is
We are down to one blocker and a few critical tickets. I’ll try to push out an
RC in a day or two.
Thanks
+Vinod
On Jun 1, 2015, at 10:45 AM, Vinod Kumar Vavilapalli
vino...@hortonworks.com wrote:
Tx for the move on that JIRA, folks.
Hi Alan,
I think you are right that CMAKE_LD_FLAGS has never done anything, and
setting it was always a mistake.
The uses of CMAKE_LD_FLAGS in JNIFlags.cmake are harmless, since the
-m32 option is not needed for the linker. However, it's more
concerning that hadoop-mapreduce-client-nativetask
Hi Darrell,
Sorry, I'm not familiar with this feature of Maven. Perhaps try
asking on the Apache Maven mailing list?
best,
Colin
On Fri, May 22, 2015 at 8:34 AM, Darrell Taylor
darrell.tay...@gmail.com wrote:
Hi,
Is it normal behaviour for maven to detect changes when I run tests with no
Hi Vinod,
Thank you for working to release 2.7!
YARN-3798 looks a critical issue for branch-2.7. I'll mark it as a
blocker of 2.7.1 if possible.
Thanks,
- Tsuyoshi
On Tue, Jun 16, 2015 at 6:58 AM, Vinod Kumar Vavilapalli
vino...@hortonworks.com wrote:
We are down to one blocker and a few
Oof. I had meant to push on this again but life got in the way and now the
June board meeting is upon us. Sorry everyone. In the event that this ends
up contentious, hopefully one of the copied communities can give us a
branch to work in.
I know everyone is busy, so here's the short version of
22 matches
Mail list logo
