Could this also explain why verify-javadoc jobs are suddenly using mvn35 instead of mvn33 ? Regards, Robert

Hello, do you have meeting minutes? Thanks, Robert

[+release] Anil is already working on it: Bye, Robert

Point well taken. A counter-example is https://git.opendaylight.org/gerrit/#/q/topic:mdsal45+(status:open+OR+status:merged): a week ago a change in MD-SAL flushed out a broken test in OFP, which showe

I do not agree with that statement. I push a ton of interlocked patches, I do reorder the patch series and I do not just push&forget. I can only stop tracking a patch when it passes verification. I am

Surely you meant 'upstream' here, right? Sam, this is a trade-off situation as to what gets discovered where, by who and how. What you are saying is that the 24 hour (max) latency of autorelease is no

I am sorry, I do not agree. mdsal ran 1005 fluorine distcheck jobs at this point as of now -- that is 45200+ VM-minutes if this job would be in place, for one project at the middle of a development cy

I stand corrected then, but my point is the same -- we have spent considerable resources to trim down distcheck back to a reasonable run time. I would hate to see going back to a world where each patc

Running multipatch on all projects takes *hours* even with -Pq -- this would enormously increase the load on our CI infra while providing protection against something which is being caught by autorele

All patches are merged now (in under 9 hours), effectively resolving TSC-99. I will leave it open until next successful autorelease build. Thank you for your contributions and patience in addressing t

-1. I do not agree. While it is convenient, this is a code change, which needs to be approved by project committers, or be explicitly delegated. Otherwise more and more such changes will be pushed int

The usual procedure would be now to start merging/verifying the patches in the order dictated by the inter-project dependency tree. We can start doing that tomorrow... Regards, Robert

+1. The interface definition contract has to live somewhere, without going into details, IOC may be a solution. Regards, Robert

This clearly shows in BFA: SFT RMI not bound Single Feature Test failed due to a java.rmi.NotBound exception in feature odl-bgpcep-programming-api . This failure is typically transient and should clea

I think you understand the Weather Item process, which is for integrating breaking work. This is a question about *embarking* on implementing a change, and the question has been asked. Let me ask you

Thank you for clearly stating your question, I finally understand it. Thanks, Robert, rejoicing in understanding.

https://jira.opendaylight.org/browse/TSC-96 Regards, Robert

Can you clearly state what you mean by "this problem", please? Regards, Robert

Hello Abhijit, The way I am reading the situation is that we have two outstanding patches to bring us over the hump -- OFP and OVSDB. Reverting means reverting also in bgpcep and lispflowmapping (IIRC

I have left comments of the ovsdb patch which should be enough to get it working. Regards, Robert