+1 This would also be a nice addition to the stick/carrots - projects who are able to live up to the requirements of the MR would get a very significant extra benefit, and failing to do so would be a

I would propose that in Sodium, we only support one release: Managed Distribution/RPM/Debs. Self-Managed projects would be responsible for generating their own distribution, as well as packaging

In the spirit of common contributions to Managed projects, I might could do this level of split. It would be a huge TODO though. Just to maintain, maybe .1-.2 FTE. That's the thing, it's not

Agreed, but I think we will at some point arrive at two releases: Platform and Managed Apps... How difficult it to maintain that? How much of the current work is really project-specific? Can we just

Reviving a very old thread, thinking we should start discussing on today's integration call. Also, from an Int/Pack perspective, two thoughts: * It was a mess to have "two" Fluorine releases (Managed,

I know it's boring, but I always point people to the autorelease job and it's dependencies.log

Hello, I'm under the impression that this POM file is the authoritative source for which projects are technically in in the MR

Oh right, I forgot about that. So I'm in the process of reworking our openstack heat macros to allow more flexibility here. However in the meantime at the shell level all that's happening is there's a

but, the image is just a name in the job definition, like this: https://github.com/opendaylight/releng-builder/blob/master/jjb/netvirt/netvirt-csit-multi-apex.yaml#L23 how am I changing that on the

Not sure why we need a new patch? The suggestion I proposed happens all at runtime, without any patches needing to be updated. The job always gets the latest image, old images always stick around.

Well, I wanted to avoid having to create a new patch every time the images were updated. That's the downside to this approach, but it might be the safest. right. Still wondering if there is another

Hi JamO, I think giving the images a unique name is the best method in my opinion and you can handle this via date / time stamp as we do with all the regular images. APEX should be no different. This

Anil, Thanh, or anyone actually, I have a problem I'm trying to figure out, but kinda stuck. We have a job [0] that updates some apex images which we use to bring up openstack w/ ODL for csit jobs.

We decided to try a new time for our meeting to make it more friendly to others that want to attend. Daniel has updated the ODL google calendar, and I will take care of the wiki. Thanks, JamO

Yes, the jobs are all passing now, thanks Anil. Daniel wrote:

Yes, the jobs are all passing now, thanks Anil. Daniel

There is more than one way to fix this, but since you are in the common distribution the easiest is to deploy the version that is already there: https://git.opendaylight.org/gerrit/#/c/76913/ BR/Luis

https://meetings.opendaylight.org/opendaylight-integration/2018/integration/opendaylight-integration-integration.2018-10-11-17.05.html

This event has been changed. more details » OpenDaylight Integration Team Meeting When Changed: Weekly from 1pm to 2pm on Thursday from Thu May 31 to Thu Oct 18 Eastern Time - New

This event has been changed. more details » Changed: ODL Integration / Docs Weekly When Changed: Weekly from 5pm to 6pm on Thursday Eastern Time - New York Where https://zoom.us/j/770709266