JRE version would be nice. Thanks, Robert

I think we need to define the core system projects can expect to be available in our runtime environment by default, e.g. scope provided. A logging implementation and osgi.core are obvious ones -- are

On the main page you need to hit reply and post your draft replies -- emails will be sent out to everyone on the reviewers list. Bye, Robert

Hello Nikos, just a quick question on this cbench variants, as there are quite a few floating by -- does this one respond to messages coming in from the controller? The Lithium codebase needs at least

+1, as a stop-gap measure this should work without major problems. Bye, Robert

Hello, Would it be possible to update the jobs either to run on master snapshots, or trigger from stable merges? Currently at least the redesign job is in a funny state where it uses 0.3.0 karaf (.e.g

What heap sizes are we running with? I think most of our tortures should be passing with 4-6GB+G1GC without issues, or am I mistaken? Thanks, Robert

https://git.opendaylight.org/gerrit/22030 fixes that. Bye, Robert

I have seen this quite a while back, but after we completed migration to karaf-3.0.3 I run the controller on JDK8 only (1.8.0u45) -- and have not had a problem since. Bye, Robert

Looks like JVM trouble -- can you try either Oracle's ARM JDK, or openjdk8? Bye, Robert

I would hope it would. How much heap can you reasonably allocate to the JVM in your deployment? I could check how the infra is dealing with that locally. Thanks, Robert

With our current gerrit setup drafts are kind of stealthy, discouraging wide and early review. While early comments may be discouraging, they can actually prevent finalizing a patch which is conceptua

+1, please do not store binary artifacts in git -- it makes it less-than-obvious from where and how they came about. The most optimal way to do this is to have a project publish them into nexus and ha

Nice catch, thanks. https://git.opendaylight.org/gerrit/27720 shows just how costly catching an exception in the caller is :-/ Bye, Robert

The error is indicative of a slow start, or an earlier failure to activate components. As noted in 4535 at least unimgr and messaging4transport are not ready for integration and should be dropped unti

A patch redirecting the messages to karaf.log has already been merged. Bye, Robert

Tracked down the offending models to armoury -- the parser will fail on them again and a patch has been submitted. Bye, Robert

Hello, Would it make sense to create a JDiff[0]-based dashboard to report on API changes from the previous release? Guava uses it to produce a very neat API difference page[1], and I think it would gi

gerrit just won't work :) Thanh: are you willing to take an AI to set it up? Or is this something we need to build on a per-project basis? Thanks, Robert

Does https://code.google.com/p/guava-libraries/source/browse/jdiff/jdiff.sh?repo=docs help? There is also a 'xerces-for-jdiff.jar'... Bye, Robert