On 30/03/15 10:22, Michal Polkoráb wrote: I think this one is obvious. We can merge it now. This will allow me to concentrate on 2825 and the benchmarks (and cascaded

Ok, sounds good. Shall I merge your changes now or are we going to wait until you set your benchmark environment up ? Michal

On 30/03/15 09:12, Michal Polkoráb wrote: This one - not yet. I started setting up a benchmark environment as I have to do proper benchmarks for the proposed fixes for ser/des as

Hi Anton, do we have any performance numbers (to compare with original code performance) ? Regards, Michal Polkorab

Looping in openflowjava-dev, where this patch is actually applied. Ed

forwarding it to openflowjava mailing list ... Anil ---------- Forwarded message ---------- From: Anton Ivanov <anton.ivanov@...> Date: Fri, Mar 27, 2015 at 1:59 PM Subject: [openflowplugin-dev]

Hello Luis, On 02/26/2015 07:28 PM, Luis Gomez wrote: ... and this is wrong, as shown by the way the jobs behaved when we changed guava version. I ended up re-merging the

Note that I am not questioning the intent, but am worried about the results as-currently-implemented. It is very important to understand what artifacts will get into that distribution,

I am not sure I follow here, can you explain more: 1) false positives, from where? 2) high-impossible to track down, the only artifact that really changes is the controller artifact, is that so

On 02/26/2015 07:53 PM, Luis Gomez wrote: Yeah, but the point is that anything that uses that distribution may end up with an inconsistent image, so you may end up with various

Hi Robert, see my comments in-line: The only requirement for 3a) is to pick new controller artifacts, whether or not we use old or new artifacts from openflowjava is not that important IMO if we

So the problem I see is the following: 1) a controller committer merges a patch 2) controller-merge-master publishes artifacts 3a) controller-distribution triggers 3b)

Hi Vrakto, Thanks for your mail, see my answers in-line. Hi Vrakto, these jobs are releng responsibility (not integration), so the question is for Andy and Thahn :) and ideally a

For some reason I neglected this mail, see my answers in-line: ${project}-integration builds the project code on upstream merges, ${project}-distribution builds the integration project on own project

Hi Luis. As your TWS talk is nearing, I would like to present my views. I think ${project}-integration job does basically the same thing as ${project}-merge, only the triggers (and

Ah... good point :) I look forward to your presentation on Monday :) Ed

That is not going to work either because a given project cannot be sure which projects are in the downstream, instead the projects in downstream will launch their system test when they see a new

Luis, Could you talk me through for example what this yaml file does: https://git.opendaylight.org/gerrit/#/c/15691/1/jjb/controller/controller-distribution.yaml I can't see a section for either

Ah... and Jenkins doesn't pass to you what jobs triggered it? Ed

That is not going to work Ed, the plan is to trigger different test plans depending on who triggers the distribution build. For that we need a distribution build per project. We discussed this in