Hi, There are other jobs with the same features that are not reporting these GC Failures. eg:

Hi, I will check today evening and let you know

Hi, I have a problem with failling Robot tests in two Jenkins jobs: - controller-csit-3node-clustering-ask-all-sulfur - controller-csit-3node-clustering-tell-all-sulfur It seems that odl_3 node is

Great, thanks! all we are missing is to update downloads page.. @LAMBERT Guillaume TGI/OLN can you help us with that? Thanks -- Daniel de la Rosa ODL Release Manager

OK, I just released the distribution with the old job name, we can fix the name for the next

I have just realized there is a typo in the distribution stage job: https://git.opendaylight.org/gerrit/c/releng/builder/+/98797 If anyone can review & merge, I can release the distribution tomorrow

Hello FYI I’ve proposed an open talk about the release process for the next DDF so that we can debate about it. About TransportPCE, since Silicon I can’t see any advantage to stay SM

Thank you Christophe and all. . @Luis Gomez , you can now proceed to release Phosphorus SR1 distribution.

Hello, I have just successfully released TransportPCE for Phosphorus SR1 tagged with version 4.1.0. You can find the log output

Hello All, OpenDaylight Phosphorus SR1 version bump is complete and the staging repository is being promoted. The 'stable/phosphorus' branch is unlocked. Pending activities required to be complete for

I wasn't really questioning why there are two release tracks. Just that it would be nice and could be possible to make the process a little simpler & more automated to reduce confusion and potential

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

AFAIK, TPCE is going to be managed from Sulfur or even Phosphorus so makes sense to consolidate to a single repo. -- Daniel de la Rosa ODL Release Manager

BTW below I meant "consolidate back to single distribution".

I think the part that is confusing is to have 2 distros so different (life-cycle, release, tagging, etc) in the same repo, I remember we did this long time back because we wanted to avoid having a new

Just 2 things: - The common distribution (opendaylight/pom.xml) has never been governed by auto-release or automatic bump for that matter, please recheck your links if you do not believe. Also the

Regarding the version mismatch for the common release, what I meant was for the karaf version in 'opendaylight/pom.xml' and the other versions - for example, release tag '14.3.0' would have the karaf

Looking at the release & version bump cycle, some of the steps may be simplified, and hopefully automated: - For each release of managed projects, release & version bump, are done separately a few

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