2018-08-09T06:17:47,637 | INFO | opendaylight-cluster-data-shard-dispatcher-45 | Shard | 214 - org.opendaylight.controller.sal-clustering-commons - 1.7.3.SNAPSHOT |

Hi team, Does anyone know what happened here? https://paste.fedoraproject.org/paste/ynvKX0LCsFIPMf13AagrQg I have a local script where I'm killing and restarting an ODL instance (just loading some

Thanks for the update. :) In the future, can you also include links to relevant Gerrits, Jiras, and similar? I'd prefer to delete them entirely. The content is never really gone, we can dig up the

+1 Thanks, Anil

This would cause a situation where someone cloning commit 123abc from autorelease is no longer guaranteed to be building the same commits from each project. The autorelease job's release flag in

+1. Regards, Robert

we're far from having any intention of doing that. This assumes a sort of much more frequently changing archetype - we're not. for me, the reason is to see impacts from changes made, such as the

JJB SCM submodule supports a tracking flag, to retrive the tip of the configured branch always. I think using the flag would avoid potential sync issues in the future. Any thoughts? " tracking

Hi, This is an update to my last week's work. - Fixed commit-msg hook issue in my local machine and successfully build upon opendaylight docs and releng/docs - Sent a patch for additional feature

Personally I think archetypes should not be part of autorelease. This allows archetypes to be able to release at any point in time and that would be useful to provide patch fixes from archetype

It is absolutely critical that when we update .gitmodules and the to update the submodule reference pointer: https://git.opendaylight.org/gerrit/75100 https://git.opendaylight.org/gerrit/75019 is

Robert, Michael: Thank you, I've merged the change #75167 and restarted AR #6. The .gitmodules seem to set to the correct branch (v2.6.x), I am not sure about this. The issue is when we update the

Depends on your point of view. It's not part of the distribution, so there is no real requirement to have in AR. This is something that was missed during creation review -- at that point the project

[forking previous thread "Re: [opendaylight-dev] [release] [OpenDaylight TSC] [releng] Fluorine branch cutting" into a new thread specifically re archetypes and autorelease follow-up] I just tried to

Hi Sam, Will try. I did rebase and was facing similar problems with a Genius one also. Oxygen and Neon were working but Flourine wasn't. Thanks and Regards, Vishal.

I've hopefully fixed it with https://git.opendaylight.org/gerrit/#/c/75167/ by doing what I've documented on

00:04:11.596 Entering 'mdsal' 00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate mdsal is not getting updated to the proper commit, which should

Micheal, Any project which is not a part of AR is presumably a self managed project, and therefore branch cutting need to be performed be the PTL. Let me know if archetypes needs to be included in AR,

Vishal, Luis's patch [1] just merged, can you see if that helps. That being said my fluorine jobs seem to be fine before this patch from my updated view yesterday. Maybe just be a problem with your

cool, now we just need to get autorelease to actually pass again... ;-) I'm still, right now, seeing various failures on