Re: [VOTE] Release Apache Aurora 0.6.0 (incubating) RC2

+1, was issue with 2 files missing headers, i've put up a patch and will be fixed in master for next release -Jake Apache Aurora release checklist - 1.1 Checksums and PGP signatures are valid. 2.1 Build is successful including automated tests. 3.1 DISCLAIMER is correct, filenames include "in

Build failed in Jenkins: Aurora #747

See Changes: [jfarrell] AURORA-933 - python missing license headers -- [...truncated 1840 lines...] = test session starts == platform linux2 -- Pytho

Re: Build failed in Jenkins: Aurora #747

Is this flakey or actually broken? On Wed, Nov 19, 2014 at 11:46 AM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [jfarrell] AURORA-933 - python missing license headers > > -

Build failed in Jenkins: AuroraBot #361

See -- [URLTrigger] A change within the response URL invocation (log) Building remotely on ubuntu-6 (docker Ubuntu ubuntu) in workspace > git rev-parse --is-inside

Re: Build failed in Jenkins: Aurora #747

only apache headers added, no code change -Jake On Wed, Nov 19, 2014 at 3:54 PM, Zameer Manji wrote: > Is this flakey or actually broken? > > On Wed, Nov 19, 2014 at 11:46 AM, Apache Jenkins Server < > jenk...@builds.apache.org> wrote: > >> See

Jenkins build is back to normal : AuroraBot #362

See

[DISCUSS] Deprecate use of mock.patch?

Hi folks, I wanted to have a discussion about the usage of mock.patch in our unit tests. In my opinion its use is a code smell versus writing production code to have explicit injection points for test dependencies. The review at https://reviews.apache.org/r/28250/ is a good example of why I think

Build failed in Jenkins: Aurora #748

See Changes: [wfarner] Add more test coverage to SchedulerThriftInterface. -- [...truncated 205 lines...] Downloading/unpacking twitter.common.collections==0.3.1 (from -r

Re: [DISCUSS] Deprecate use of mock.patch?

As I mentioned in that review, I'm not sold on the idea. I feel that it leads to a fair amount of extra code that exists solely to support testing. One of the nice things about dynamic languages is they allow you to avoid this sort of boilerplate. The main problem in that review is just that the wr

Jenkins build is back to normal : Aurora #749

See

Re: [DISCUSS] Deprecate use of mock.patch?

I am with Joshua on this. The increased complexity and indirection is not the tradeoff I would fight for. The lack of coverage is a bigger problem in my opinion. Requiring patch-less unit tests may just encourage a proliferation of un-pythonic patterns and more obstacles on the way to improving our

Build failed in Jenkins: Aurora #750

See Changes: [wfarner] Ensure all verbs return an exit code. -- [...truncated 204 lines...] Downloading/unpacking twitter.common.collections==0.3.1 (from -r

Re: [DISCUSS] Deprecate use of mock.patch?

I'm actually waffling on my stance. I tried to frame it mentally in the context of how I'd handle the same use case in javascript (a language I'm much more comfortable with than Python), and I'd have a hard time arguing in favor of a similar mechanism there (e.g. in node.js patching require to glob

Re: [DISCUSS] Deprecate use of mock.patch?

I don't think this a dynamic vs static language thing - if this were Java we could just as easily do public class MyTest { private PrintStream oldSystemOut; @Before public void setUp() { oldSystemOut = System.out; System.setOut(mockPrintStream); } @After public void tearDown(

Re: [DISCUSS] Deprecate use of mock.patch?

That's a fairly contrived example though, as most Java classes don't expose a mechanism for injecting mocks. I think points #3 and #4 make the strongest case for why we'd want to avoid this (though I don't believe we currently run tests in parallel so #4 is more of a nice-to-have). If it's general

Jenkins build is back to normal : Aurora #751

See

Re: [VOTE] Release Apache Aurora 0.6.0 (incubating) RC2

Hash and signatures are good. DISCLAIMER is correct LICENSE and NOTICE files look good No 3rd party executables +1 (binding) Thanks guys! On Thu, Nov 13, 2014 at 2:33 PM, Bill Farner wrote: > All, > > I propose that we accept the following release candidate as the official > Apache Aurora 0.6.0