+1. Regards, Robert

-1, this is a very useful downstream of OFP. Perhaps we may merge it with it. +1 +1 +1 +1 +1 +1 +1 +1 +1 Not sure, this project was in some sort of a handover last time I checked... Regards, Robert

Yes, Silicon SR3 has shown TCPE can easily manage being an MRI project. Unimgr is irrelevant, as they still work on kernel from a few years back. Regards, Robert

Yes there is and there is quite a bit of history attached to that. Our governance clearly states that each project is independent, which in this context means is free to release whenever as well as ca

Three, actually. Yes, and therefore the release lifecycle of int/dist is unlike any other project I have come across. Right-o, but unfortunately you are explaining something completely off-topic, so l

This boils down to interaction between autorelease and int/dist. autorelease assumes branch cutting involves bumping minor version, which has been true for all MSI projects since forever. int/dist sta

Well, that's true, but then spinning a new release of a single project is quite straightforward, so TPCE can run as fast as kernel projects are integrated into int/dist -- it even could become an MRI

Hmm, just got a message about maintenance being complete, wiki/gerrit/jira work, but jenkins is reporting a 502. Regards, Robert

Hello Anil, This looks nice and works in Jenkins, but unfortunately in Gerrit we still get references to logs (in https://git.opendaylight.org/gerrit/c/controller/+/97722): I am not sure where these a

Ack, everything seems to be working again. Thanks, Robert

n 01/10/2021 09:30, Anil Belur wrote: Awesome, this is what we want to be aiming for and we will be establishing MRI project release process in terms of pipelines as soon as we get the green light :)

I think netconf devs would be less confused if you could share some writeup of how exactly is test execution wired across integration/test and releng/builder :) Please note that NETCONF is an MRI proj

So the mri-test-phosphorus does not kick off of autorelease, but runs periodically. I have kicked off #40, but #39 should be accurate. Regards, Robert

Okay, so we have one remaining issue in BGPCEP, but after spending today trying to make sense of what is going on, it is not a regression, just shifted timing in code. It may have been detected transi

Okay, I think I found the culprint. A fixed bgpcep should be out in about two hours or so and should be reflect in next AR build. Bye, Robert

Alright, this looks like a pccmock issue: https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/bgpcep-csit-1node-userfeatures-all-phosphorus/179/robot-plugin/log.html.gz#s1-s2-k2-k3 https://jira

Yeah, it's three test cases, all of them are PCEP-related. They are failing reliably, which seems to indicate a systemic problem. I'll try to see if I can debug/repro it tomorrow. We might punt to SR1

To explain: it is failing since Sep 21, hence Jenkins jobs do not reflect Gerrit branches mapping: - all -phosphorus jobs still refer to master branch - there are no -sulfur jobs Regards, Robert

It seems Jenkins/JJB integration is busted. I have filed https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-22956 for that. Bye, Robert

It seems we have a few regressions in both BGP and PCEP. I suspect I know the culprit behind at least one of the failures, should have an updated bgpcep ready later today. Regards, Robert