Please continue the governance discussion here so we can reach concrete proposals for TSC vote. I personally do not see difference between "5 seats now + 2 seats later" vs "5 seats now and new TSC wil

I think this could be done just before a release milestone (e.g. for a RC) but difficult to achieve in a continuous way like in AR today, specially when projects will have freedom for updating their u

I also do not think TSC can obligate a project to release but I think we have to set some rules for functioning together, for example Platform projects should define a set of release versions for Plug

Hi all, I personally found very interesting the ODL release model conversation we held in DDF. In particular I would like to see if the current project classification and release model: MRI, MSI, SM c

+1, the simpler, the better.

The way things work in ODL, it is not possible to have a Managed project depending on an SM project. So if lispflowmapping project wants to continue as Managed project, it should either: - Remove neut

Thanh, Anil, couple of things: - I see lot of issues with the docs linkcheck (multiple rechecks required to pass a build), would it be possible to relax or maybe remove this check? - Can we switch the

Casey, I do not see an invite for IST friendly bi-weekly meetings. If these require passcode, please send invite for these too.

Fine with me.

Thanks Brandon, I just recalled Lumina used ODL based controller in this interop effort: http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf (it is also m

Tejas/Prem/Allan, any plan to release odlmicro/odlsaf/plastic for Aluminum release? If so we could add some messaging in the Aluminum press release. FYI, to release an SM project you normally have to

I do not see anyone else joining the common karaf distribution so I went ahead and released it: https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/op

Hi Ahmed, I see some of the questions also apply to non DC use cases so maybe we can structure the questions as follows: Do you use SDN? If No, what is the reason for not adopting SDN? (add Other to t

FYI in current release process, SM projects are not checked at all, they are responsible to deliver valid release based on the right version. BR/Luis

BTW tomorrow I have kids doctor appointment at 8AM, I should be done by 9AM, but if I am late Jamo can start with int/test Q&As. BR/Luis

Sodium SR4 common distribution is released here: https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/opendaylight/0.11.4/ Please proceed with post-rel

Hi Guillaume, Even if there is no changes in TPCE between Sodium SR3 and SR4, if you do not produce a release for Sodium SR4, any downstream picking ODL Sodium SR4 (e.g. ONAP) will not be able to run

FYI there are a bunch of CSIT jobs failing like this one: https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1node-gate-flow-services-all-silicon/2/console The issue is reported here: htt

Hello everyone, Mg SR2 official release is available here: https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/opendaylight/0.12.2/ Please proceed wit

Not sure if this is tribal knowledge but every release I have to manually patch JJB for some misses: https://git.opendaylight.org/gerrit/c/releng/builder/+/87973 I have not checked yet the patch for t