> On Nov 30, 2017, at 1:07 AM, Rohith Sharma K S
> wrote:
>
>
> >. If ATSv1 isn’t replaced by ATSv2, then why is it marked deprecated?
> Ideally it should not be. Can you point out where it is marked as deprecated?
> If it is in historyserver daemon start, that change made very long back when
> On Dec 1, 2017, at 12:18 PM, Rushabh Shah wrote:
> Can someone explain me what happened ?
Yetus downloaded the patch to make sure it applied before bothering to
do anything else to make sure it wasn’t going to burn cycles on the build boxes
for no reason. Docker mode was active so i
> On Dec 1, 2017, at 1:36 PM, Jason Lowe wrote:
> I thought the admin precommit build was kicking off the project-specific
> precommit build with an attachment ID argument so the project precommit can
> be consistent with the admin precommit build on what triggered the precommit
> process.
Here’s the date of the last commit by email address (or, at least, what git
thinks is the email address…) and the commit hash. People-wise, there are some
obvious dupes here but I’m too lazy to filter them out. ;)
2014-09-27 ste...@apache.org 7f300bcdc78d164a42d56c3f65a512cfe0ac40be
2014-09-2
No illustration, as it isn't an image.
On Sep 28, 2014, at 2:12 PM, Roman Shaposhnik wrote:
> And this illustrates what exactly?
>
> Thanks,
> Roman.
>
> On Sun, Sep 28, 2014 at 2:01 PM, Allen Wittenauer wrote:
>>
>> Here’s the date of the last commit b
On Sep 28, 2014, at 2:25 PM, Roman Shaposhnik wrote:
> On Sun, Sep 28, 2014 at 2:17 PM, Allen Wittenauer wrote:
>>
>> No illustration, as it isn't an image.
>
> And I suppose it has no point either, then. So perhaps it doesn't belong
> to the public mail
I think people forget we have a wiki that documents this and other things ...
https://wiki.apache.org/hadoop/HowToContribute#Naming_your_patch
On Dec 2, 2014, at 10:01 AM, Tsuyoshi OZAWA wrote:
>> .[branchName.].patch*
>
> +1 for this format. Thanks for starting the discussion, Yongjun.
>
> -
sys_errlist was removed for a reason. Creating a fake sys_errlist on Solaris
will mean the libhadoop.so will need to be tied a specific build
(kernel/include pairing) and therefore limits upward mobility/compatibility.
That doesn’t seem like a very good idea.
IMO, switching to strerror_r i
On Dec 13, 2014, at 4:05 AM, Steve Loughran wrote:
>
> The shell scripts are also undertested and only intermittently maintained
> —there's been recent work there in HADOOP-9902(?) which is a great
> improvement to trunk. If you can help test the CLI on your OS, that will
> save you support cal
On Dec 14, 2014, at 8:38 AM, Allen Wittenauer wrote:
>
> On Dec 13, 2014, at 4:05 AM, Steve Loughran wrote:
>>
>> The shell scripts are also undertested and only intermittently maintained
>> —there's been recent work there in HADOOP-9902(?) which is a great
&g
On Dec 20, 2014, at 9:09 AM, Raghavendra Vaidya
wrote:
> I have been struggling to setup hadoop code with native libraries on mac
> osx this gave me an idea to write a utility which can help setup
> hadoop development environment either on intellij or eclipse including
> local libraries ….
On Dec 20, 2014, at 10:23 PM, Raghavendra Vaidya
wrote:
> HEre is the exception I get when I execute maven install -Pnative ...
> please note that I have installed Protobuf and openssl using Brew on Mac OSX
>
> around Ant part ... dir="/Users/302000545/Documents/workspace/Hadoop/hadoop-comm
IIRC, it was marked as evolving because it wasn’t clear at the time
whether we would need to add more stability levels. (One of the key
inspirations for the stability levels—Sun’s ARC process—had more.)
So I think it’s important to remember that if this gets changed to
stable,
Adding or removing annotations has no effect on the correct linkage of the
> binary representations of programs in the Java programming language.
>
> Certainly removing existing levels would be backwards-incompatible.
>
> Chris Nauroth
> Hortonworks
> http://hortonwor
The fact that reviews.apache.org has ~35k users (
https://reviews.apache.org/users/?page=711 ) that mostly appear to be bots
gives me zero confidence in using this tool for anything real.
On Jan 30, 2015, at 11:11 AM, Gera Shegalov wrote:
> Splitting the conversation via reviewboard and JIRA
Is process really the problem? Or, more directly, how does any of this
actually increase the pool beyond the (I’m feeling generous today) 10 or so
committers (never mind PMC) that actually review patches that come from outside
their employers on a regular basis?
To put this in
IMO, HDFS-5796 (in some form or another) is a blocker for 2.7.
Right now, DFS browsing is pretty much broken on secure systems when a
hadoop-auth-compatible plugin is in use. The "fix" (HDFS-5716) introduced
(what appears to be) an incompatible and undocumented method to provide auth
versus
The big question is whether or not Java’s implementation of Kerberos
supports it. If so, which JDK release. Java’s implementation tends to run a
bit behind MIT. Additionally, there is a general reluctance to move Hadoop’s
baseline Java version to something even supported until user ou
Between:
* removing -finalize
* breaking HDFS browsing
* changing du’s output (in the 2.7 branch)
* changing various names of metrics (either intentionally or otherwise)
* changing the JDK release
… and probably lots of other stuff in branch-2 I hav
One of the questions that keeps popping up is “what exactly is in trunk?”
As some may recall, I had done some experiments creating the change log based
upon JIRA. While the interest level appeared to be approaching zero, I kept
playing with it a bit and eventually also started playing with the
Is there going to be a general upgrade of dependencies? I'm thinking of jetty
& jackson in particular.
On Mar 5, 2015, at 5:24 PM, Andrew Wang wrote:
> I've taken the liberty of adding a Hadoop 3 section to the Roadmap wiki
> page. In addition to the two things I've been pushing, I also looke
witch).
>
> On Thu, Mar 5, 2015 at 9:21 PM, Allen Wittenauer wrote:
>
>>
>> Is there going to be a general upgrade of dependencies? I'm thinking of
>> jetty & jackson in particular.
>>
>> On Mar 5, 2015, at 5:24 PM, Andrew Wang wrote:
>>
&g
Between this and the other thread, I’m seeing:
* companies that were forced to make internal forks because their
patches were ignored are now considered the deciders for whether we move forward
* 5 years since the last branch off of trunk is considered ‘soon’
* M
On Mar 10, 2015, at 12:40 PM, Karthik Kambatla wrote:
>
> Are we okay with breaking other forms of compatibility for Hadoop-3, like
> behavior, dependencies, JDK, classpath, environment? I think so. Are we
> okay with breaking these forms of compatibility in future Hadoop-2.x?
> Likely not. Doe
I think the general consensus is don’t include the changes.txt file in your
commit. It won’t be correct for both branches if such a commit is destined for
both. (No, the two branches aren’t the same.)
No, git log isn’t more accurate. The problems are:
a) cherry picks
b) branch mergers
c) “who
the jira side and
> refreshing the result.
>
> I wonder if we as a community should switch to using your way, and save
> committer's effort of taking care of CHANGES.txt (quite some save IMO).
> Hope more people can share their thoughts.
>
> Thanks.
>
> --Yong
olve
>>>> d by pulling this info from jira as Sean pointed out.
>>>>
>>>> Problem b (branch mergers) seems to be a real one, and your approach of
>>>> using JIRA system to build changes.txt is a reasonably good way. This
>> does
>
> commits or report redundant commits on a branch with merged
> ancestor branches?
>
> Thanks.
>
> --Yongjun
>
>
> On Tue, Mar 17, 2015 at 11:21 AM, Allen Wittenauer wrote:
>
>>
>>Nope. I’m not particularly in the mood to write a book about a
>&
On Mar 18, 2015, at 2:32 PM, Andrew Wang wrote:
>
> The bigger question for me is why we have CHANGES.txt at all when we have
> release notes, since the information is almost identical.
Yeah, I don’t think it was always like that. Stripping it down to just the
ones that actually have releas
Hi folks,
There are ~6,000 Hadoop JIRA issues that have gone unaddressed,
including ~900 with patches waiting to be reviewed. Among other things, this
lack of attention to our backlog is making the Hadoop project very unfriendly
to contributors--which is ultimately very unhealthy for
It would be great if everyone could make sure that when resolving a
JIRA Issue that they:
A) Make sure that their final message is actually in the comment box and not in
the release notes box. For 2.7, there are currently 5 out of the 24 release
notes that are +1 type messages
How would you propose we use SELinux features to support security,
especially in a distributed manner where clients might be under different
administrative controls? What about the non-Linux platforms that Hadoop runs
on?
On Mar 26, 2015, at 3:46 AM, Madhan Sundararajan
wrote:
>
xperience certainty. IT Services
>Business Solutions
>Consulting
>
>
>
>
> From: Allen Wittenauer
> To: common-dev@hadoop.apache.org
> Date: 03/26/2015 06:51 PM
> Subject:Re: Hadoop Common: Why not re-use the Securit
Very likely. One of the things I noticed during HADOOP-11746 is that
there is a HUGE, catastrophic race if Jenkins doesn’t setup the environment
correctly or leaks variables between runs. shellcheck prints out so many
messages on the current code I’m surprised it doesn’t crash.
On Ma
nch for working on
> improving our test-patch scripts, Allen.
>
> On Tue, Mar 31, 2015 at 9:37 AM, Allen Wittenauer wrote:
>
>>
>>Very likely. One of the things I noticed during HADOOP-11746 is
>> that there is a HUGE, catastrophic race if Jenkins doesn’t s
Hello everyone!
(to: and reply-to: set to common-dev, cc: the rest of ‘em, to
concentrate the discussion)
HADOOP-11731 has just been committed to *trunk*. This change does two
things:
a) Removes dev-support/relnotes.py
b) Adds dev-support/releasedocmaker.py
releasedoc
On Apr 2, 2015, at 9:51 AM, Karthik Kambatla wrote:
>>
>> a) remove CHANGES.TXT from trunk
>>
>
> Removing this from trunk makes it particularly hard to cherry-pick changes
> from trunk to branch-2. I would gate this on the removal of CHANGES.txt on
> branch-2 as well, at least until we have s
On Apr 2, 2015, at 11:36 AM, Mai Haohui wrote:
> Hi Allen,
>
> Thanks for driving this. Just some quick questions:
>
>>> Removing changes.txt, relnotes.py, etc from branch-2 would be an
>>> incompatible change. Pushing aside the questions of that document’s
>>> quality (hint: lots of
On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli
wrote:
>
> We'd then doing two commits for every patch. Let's simply not remove
> CHANGES.txt from trunk, keep the existing dev workflow, but doc the release
> process to remove CHANGES.txt in trunk at the time of a release going out of
Find and fix the mistake made in the past 24 hours to the git log (and
changes.txt as well, so no help there!).
On Apr 7, 2015, at 8:56 AM, Allen Wittenauer wrote:
>
> Find and fix the mistake made in the past 24 hours to the git log (and
> changes.txt as well, so no help there!).
>
>
… and no, it isn’t that YARN-2666 is missing it’s JIRA in the changes.txt.
That’s too easy
On Apr 7, 2015, at 10:03 AM, Chris Nauroth wrote:
> Is this a trick question, because you really can't "fix" prior commits in
> the git log without a forced push, which then invalidates everyone's
> cloned copy of the repo? :-)
There is an error that would require such a thing, yes. :D
For those wondering, YARN-2429 is the wrong JIRA for that commit. Simple typo,
but deadly if one is using to use the git log to determine what’s actually
committed...
Cancel the patch and it won’t do that.
Also, FWIW, HADOOP-11746 makes test-patch.sh run significantly faster for
non-Java patches. (of course, the current test-patch doesn’t publish times, so
it’s hard to know how slow it is. lol)
On Apr 8, 2015, at 12:39 AM, Gopal Vijayaraghavan wrote:
> H
s much.
>>>
>>> I certainly have no objection to generating CHANGES.txt and release
>>> notes off JIRA, which avoids some of these problems (jiras can be
>>> edited, after all). But JIRA has its own set of problems... it's not
>>> always availab
. Let's go ahead and file a jira for
> it, unless others have objections.
>
> Chris Nauroth
> Hortonworks
> http://hortonworks.com/
>
>
>
>
>
>
> On 4/8/15, 8:32 AM, "Allen Wittenauer" wrote:
>
>>
>> Cancel the patch and it wo
Someone should look into HDFS-8132, which appears to have been filed against
RC0.
On Apr 11, 2015, at 1:44 AM, Vinod Kumar Vavilapalli wrote:
> Hi all,
>
> I've created a release candidate RC0 for Apache Hadoop 2.7.0.
>
> The RC is available at: http://people.apache.org/~vinodkv/hadoop-2.7.
16, 2015, at 7:38 PM, Chris Nauroth wrote:
> I'd like to thank Allen Wittenauer for his work on HADOOP-11746 to rewrite
> test-patch.sh. There is a lot of nice new functionality in there. My
> favorite part is that some patches will execute much faster, so I expect
> this will
FYI, MAPREDUCE-6324 is the first JIRA to be tested with the new code in place
if someone hasn’t seen the new output.
On Apr 21, 2015, at 9:06 PM, Allen Wittenauer wrote:
>
>
> Just a heads up that I’ll be committing this to trunk and branch-2 here
> in a bit. I’ll watch
good news! The new mvn site test does appear to be capable of
catching issues! YARN-3410 was committed just prior to the new test code and
has markdown-to-html syntax issues. HADOOP-11627 (for example) shows the
results. :D
On Apr 21, 2015, at 10:48 PM, Allen Wittenauer wrote:
>
&g
Err, first jira mentioned should be HADOOP-11861.
On Apr 22, 2015, at 8:10 AM, Allen Wittenauer wrote:
>
> Some status:
>
> * So far, HADOOP-11627 was filed which is luckily an extremely easy bug to
> fix.
>
> * There have been a few runs which seems to indicat
Hey gang,
Just so everyone is aware, if you are working on a patch for either a
feature branch or a major branch, if you name the patch with the branch name
following the spec in HowToContribute (and a few other ways… test-patch tries
to figure it out!), test-patch.sh *should*
Vavilapalli
wrote:
> Does this mean HADOOP-7435 is no longer needed / closeable as dup?
>
> Thanks
> +Vinod
>
> On Apr 22, 2015, at 12:34 PM, Allen Wittenauer wrote:
>
>>
>> Hey gang,
>>
>> Just so everyone is aware, if you are working on
Oh, this is also in the release notes, but one can use a git reference # as
well. :) (with kudos to OOM for the idea.)
On Apr 22, 2015, at 8:57 PM, Allen Wittenauer wrote:
>
> More than likely. It probably needs more testing (esp under Jenkins).
>
> It should be noted that
On Apr 22, 2015, at 11:34 PM, Zheng, Kai wrote:
> Hi Allen,
>
> This sounds great.
>
>>> Naming a patch foo-HDFS-7285.00.patch should get tested on the HDFS-7285
>>> branch.
> Does it happen locally in developer's machine when running test-patch.sh, or
> also mean something in Hadoop Jen
On Apr 24, 2015, at 3:09 AM, Brahma Reddy Battula
wrote:
> The patch artifact directory on has been removed!
> This is a fatal error for test-patch.sh. Aborting.
> Jenkins (node H8) information at
> https://builds.apache.org/job/PreCommit-YARN-Build/7477/ may provide some
> hints. ( did I mi
On Apr 23, 2015, at 7:57 PM, Sidharta Seethana
wrote:
> About (3.) , a lot of the check style rules seem to be arcane/unnecessary.
> Please see : https://issues.apache.org/jira/browse/HADOOP-11869
a) I've closed it as a dupe of HADOOP-11866 to keep everything in one place.
b) I've had HADO
On Apr 24, 2015, at 11:41 PM, Vinod Kumar Vavilapalli
wrote:
>
> Marco Zühlke pinged me offline informing me that I completely got my
> issue-count wrong.
>
> Seems like I had a very bizarre filter, I missed closing some tickets too at
> release time.
You were probably counting cha
(Reply-to set to common-dev@)
With over 900 patches not yet reviewed and approved for Apache Hadoop,
it's time to make some strong progress on the bug list!
A number of Apache Hadoop committers and Hadoop-related tech companies
are hosting an Apache Hadoop Community event on Fri
Here’s the link in case you didn’t see it:
https://www.eventbrite.com/e/apache-hadoop-global-bug-bash-tickets-16507188445
Whether you are working virtually or in-person, it’s important for
everyone participating to register so that we can keep track of global
p
Hey gang.
With the commit of HADOOP-11866, the output for checkstyle and
whitespace has been greatly enhanced to actually be useful now. Instead of
getting weird output, you'll see the file, the line number and (in the case of
checkstyle) error. Note that line numbers are aft
So, as some may have noticed, I slammed the Jenkins servers over the
weekend to get some recent patch test runs in JIRA for the bug bash this week.
I've had a suspicion for a while now that either the long run times of the
hadoop-hdfs module unit tests (typically 2+ hours) or t
gt;> guarantees about files out of the main workspace.
>>
>> They all write to ${WORKSPACE}/../patchProcess, which will probably
>> collide
>> if multiple runs happen on the same machine. They also all blindly move
>> that directory at the end of the run.
>>
On May 5, 2015, at 11:05 AM, Rich Haase wrote:
> Can someone explain to me why on earth we care about limiting line length to
> 80 characters? Are there hadoop developers out there working from teletype
> terminals? Can we perhaps update this limit to something sane, like 120
> chars?
>
TL;DR:
Heads up: I’m going to hack on these scripts to fix the race
conditions.
Presently, we have a pretty wicked race condition in the precommit
scripts, namely writing to a directory that is outside of Jenkins' workspace
directory. I’ve committed changes this morning
HDFS, MAPREDUCE, and YARN have been migrated.
Let me know of any issues and I’ll try to get to them as I can. This should be
the end of the Jenkins race conditions for our pre commits! *crosses fingers*
Hey gang!
A couple of things in regards to the Bug Bash on Friday:
* We’ll be closing registrations to the Bug Bash on May 6th at
3PM Pacific time. So make sure you do it son:
https://www.eventbrite.com/e/apache-hadoop-global-bug-bash-tickets-165071884
On May 5, 2015, at 8:10 PM, Allen Wittenauer wrote:
> * We’ll be closing registrations to the Bug Bash on May 6th at
> 3PM Pacific time. So make sure you do it son:
> https://www.eventbrite.com/e/apache-hadoop-global-bug-bash-tickets-16507188445
That
May we declare this branch dead and just close bugs (but not
necessarily concepts, ideas, etc) with won’t fix? I don’t think anyone has any
intention of working on the 1.3 release, especially given that 1.2.1 was Aug
2013 ….
I guess we need a PMC member to declare a vo
On May 11, 2015, at 10:23 AM, Wangda Tan wrote:
> Hi Hadoop-dev,
>
> Now we are working on branch-2.7 for 2.7.1 release but I found branch-2.7
> may not be added to Jenkins white list. For example: YARN-3434 cannot
> trigger Jenkins build.
>
> Could anybody help to add it?
It’s not a white l
On May 11, 2015, at 10:34 AM, Allen Wittenauer wrote:
>
> It’s not a white list; it’s done heuristically. If you read through the
> release notes of HADOOP-11746, you’ll see that it only supports major
> branches. It does not (currently?) support minor or micro branches. (Th
Anyone know if these machines are supposed to be in the Ubuntu pool on
Jenkins? Given they are H-machines, shouldn’t they been in the Hadoop pool?
Right now, we’ve got stuff waiting with zero test slots available while the
Ubuntu pool has slots open that we can’t use. :(
Hi.
A few times now, we’ve run into issues where we weren’t sure what sort
of state the surrounding environment was present when a pre commit patch test
was done. Additionally, there are times when installing or even updating a
component was a challenge. There are some bits
On May 13, 2015, at 5:02 AM, Alan Burlison wrote:
> The current version of Protocol Buffers is 2.6.1 but the current version
> required by Hadoop is 2.5.0. Is there any reason for this, or should I log a
> JIRA to get it updated?
The story of protocol buffers is part of a shameful pas
Hey gang.
I promised a post-mortem, but I got distracted with making everyone's
lives miserable with new test-patch code. Luckily my coworker Barbara (who
some of you met!) wrote some wrap up info about it on our corporate blog,
including some interesting stats….
htt
On May 28, 2015, at 9:36 AM, Sangjin Lee wrote:
> Hi folks,
>
> I noticed this while setting up a cluster based on the current trunk. It
> appears that setting HADOOP_HOME is now done much later (in
> hadoop_finalize) than branch-2. Importantly this is set *after*
> hadoop-env.sh (or yarn-env.s
On May 28, 2015, at 11:29 AM, Sangjin Lee wrote:
> Thanks Chris and Allen for the info! Yes, we can use HADOOP_PREFIX
> until/unless HADOOP-11393 is resolved.
>
> Just to clarify, we're not setting HADOOP_HOME/HADOOP_PREFIX in our
> *-env.sh; we simply use them. I don't know that it is always f
On Jun 12, 2015, at 12:37 AM, Sitaraman Vilayannur
wrote:
> Hi,
> What is the limit on the number of properties that can be set using
> set(String s1, String s2) on the Configuration object for hadoop?
> Is this limit configurable if so what is the maximum that can be set?
It's a "tot
On Jun 14, 2015, at 1:00 PM, Yongjun Zhang 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
> pre-commit test
On Jun 12, 2015, at 1:03 PM, Alan Burlison 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 not seeing a sign
ts. Right now, the proposed PMC would be (alphabetical by last
> name):
>
> * Andrew Bayer (ASF member, incubator pmc, bigtop pmc, flume pmc, jclouds
> pmc, sqoop pmc, all around Jenkins expert)
> * Sean Busbey (ASF member, accumulo pmc, hbase pmc)
> * Nick Dimiduk (hbase pmc, phoenix
On Jun 16, 2015, at 2:54 AM, Steve Loughran wrote:
One reason at least: PB 2.5.0 has no support for Solaris SPARC. 2.6.1 does.
>
> to be ruthless, that's not enough reason to upgrade branch-2, due to the
> transitive pain it makes all the way down.
Not in branch-2, but cert
Since a couple of people have brought it up:
I think the release question is probably one of the big question marks.
Other than tar balls, how does something like this actually get used
downstream?
For test-patch, in particular, I have a few thoughts on this:
Short term:
We should probably file and work some liras to remove excess whitespace, tabs,
etc. from the source files.
> There are some known issues with false positives on the whitespace check
> right now. Fixes are in progress.
fixes for this and a bunch of other issues are already fixed upstream. ;)
If 2.6 is the target, someone will have to verify that any
cherry-picked patches actually work with JDK6 since the PMC voted to officially
kill backward compatibility in a minor release. It’s going to be easier and
probably smarter to fix 2.7 if that’s really desired. [1]
Frank
On Jun 23, 2015, at 1:32 PM, Alan Burlison wrote:
> I'm trying to test stuff prior to submission, following the instructions at
> http://wiki.apache.org/hadoop/HowToContribute and even when using an
> unmodified git clone from the repo on a LLinux machine I've failed to get a
> clean test run
On Jun 24, 2015, at 10:03 AM, Sean Busbey wrote:
> On Wed, Jun 24, 2015 at 2:10 AM, Ray Chiang wrote:
>
>> Thanks, dev-support sounds good. The only question I have is that there
>> isn't a pom.xml there now. Is that something we'd want to have there? And
>> should it at least be linked to
On Jun 27, 2015, at 1:53 PM, Roman Ivanov wrote:
> Hi,
>
Howdy!
> I noticed Checksyle usage in Hadoop project
> https://github.com/apache/hadoop/blob/trunk/hadoop-build-tools/src/main/resources/checkstyle/checkstyle.xml
>
> but latest sources generate about 200 errors by command "m
On Jun 26, 2015, at 3:35 PM, Andrew Wang wrote:
> Allen, do you still have these concerns? You mentioned having written
> scripts to parse CHANGES.txt. I've written scripts for similar tasks, but
> what I turned to were git log and JIRA, not CHANGES.txt. I was wondering if
> this is a relic from
I think it defeats the purpose ofu
On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa wrote:
> +1, thanks Allen and Andrew for taking lots effort!
>
>> Is there any possibility that, we can restrict someone from editing the
>> issue in jira once its marked as "closed" after release?
>
> Vinay's comm
On Jul 13, 2015, at 2:52 AM, Steve Loughran wrote:
>
> nothing particular, except I want to do something better with test running
> and reporting
...
> ultimately I'd like to be able to stream test events from test runners & log
> events from (distributed) processes together for a linearize
On Jul 14, 2015, at 3:08 AM, Bruno P. Kinoshita
wrote:
> Hi
> Has anyone considered using TAP (Test Anything Protocol) for test reporting?
> [1][2]
> disclaimer: I'm the maintainer of the Jenkins TAP plug-in and tap4j Java
> library
Just to be clear: yetus is about the layer betwee
On Jul 15, 2015, at 11:22 PM, Bruno P. Kinoshita
wrote:
>
> Good points. This layer between Jenkins and the unit tests seems useful.
Thanks!
We think so too! It’s why we’re working on pulling the code out of
Hadoop to make it more generalized for lots of different projects.
On Jul 17, 2015, at 3:07 AM, Steve Loughran wrote:
>
>> On 16 Jul 2015, at 16:05, Allen Wittenauer wrote:
>>
>> “convert this directory of TAP-formatted files to JUnit XML”.
>
> FWIW it's Ant JUnit XML Reporter-formatted XML. Just to make the origins
> c
Could whoever created the master branch please delete it?
Thanks.
I hope someone tests this against JDK6, otherwise this is an incompatible
change.
On Aug 12, 2015, at 2:21 PM, Chris Nauroth wrote:
> I've just applied the 2.6.1-candidate label to HADOOP-10786. Since this
> is somewhat late in the process, I thought I'd better follow up over email
> too.
>
On Aug 27, 2015, at 8:21 AM, Sean Busbey wrote:
>
> Allen, you've been chugging away at the build support changes in
> test-patch[4]. That looks like it's going to change a bunch of stuff.
> Should we wait for it to land to have an initial release?
I think so, yes. It’s getting very ve
On Sep 9, 2015, at 6:00 PM, Vinod Kumar Vavilapalli wrote:
> - Note that branch-2.6 which will be the base for 2.6.2 doesn't have these
> fixes yet. Once 2.6.1 goes through, I plan to rebase branch-2.6 based off
> 2.6.1.
Isn’t there a risk that there are things in branch-2.6 that aren’t
Hello!
Important message, visit http://cjmirra.com/town.php?07m95
Allen Wittenauer
Hello!
Important message, visit http://abcbordados.com.br/family.php?wj28o
Allen Wittenauer
301 - 400 of 1325 matches
Mail list logo
