Avishnoi seeing this issue assigned to you, can you confirm that you are planning to work on this? This week? 
FYI https://wiki.opendaylight.org/view/Neon_platform_upgrade has step-by-step instructions ...
vorburgerI've raised a preliminary patch for this after referring the above instructions. I ve some queries
1.Regarding "New features are available to wrap the dependencies like odl-apache-commons-codec", are these present under odlparent. Would be useful if you could point me to some examples.
2.Regarding "mdsal related impacts"(Moving to rfc6991 from yang-types and inet-types) the dependencies in xml, shouldn't we also do the same in yang models using these models?
3. I ve started seeing new findbugs failures. Has the findbug configuration changed too?
> 1.Regarding "New features are available to wrap the dependencies like odl-apache-commons-codec", are these present under odlparent. Would be useful if you could point me to some examples.
ivan.hrasko@pantheon.tech (ivanhrasko) has done this for SXP in https://git.opendaylight.org/gerrit/#/c/76164/ ... but differently than I personally would have; I'm also unclear whether dependencies to these new features should be added to bundles (as in c/76164/7) or only a projects odl-* features to override the feature.xml ... skitt tpantelis rovarga any thoughts about this? I've added a TODO on https://wiki.opendaylight.org/view/Neon_platform_upgrade#Feature_changes which should be updated after has been clarified.
> 2.Regarding "mdsal related impacts"(Moving to rfc6991 from yang-types and inet-types) the dependencies in xml, shouldn't we also do the same in yang models using these models?
Perhaps; could I invite you to contact the the mdsal-dev list for clarification? Please do update the Wiki with any new information useful to others you learn about!
> 3. I ve started seeing new findbugs failures. Has the findbug configuration changed too?
Yes, there are some known hiccups related to null analysis, and the Wiki is missing documentation about what they are and how to best work around them. The odlparent Release Notes here https://github.com/opendaylight/odlparent/blob/v4.0.0/NEWS.rst do say something about it, but if you could add something (perhaps in an more "prescriptive" style, like "if you hit this error then do that") to the Wiki, that would be great. If any doubt, best to post to odlparent-dev about it and ask for clarification.
I’ve updated the wiki page to explain how and where to add feature dependencies.
vorburger why is this due on September 27? The Neon version bump only starts on October 6, this mustn’t be merged earlier than that.
Of course, of course (on the contrary, personally I really don't want any of the neon-mri changes to be merged before we have a full passing multipatch build and netvirt CSIT passing!); the due dates I have set yesterday not just on this but all neon-mri issues was to propose a "project plan" by when, latest, we need to see working patches, so that everything aligns, in terms of the dependencies between projects. Check out the neon-mri dashboard (now also part of the Release dashboard), to see them nicely ordered by Due date. Let's talk more about this face to face on Sunda at the DDF at ONS!
Right, that’s what I suspected. My fear was that, since not all PTLs and committers pay attention to the project as a whole, setting due dates on these bugs could be mis-interpreted as a sign that the corresponding patches should be merged (although that would require them to build correctly which is unlikely).
vorburger I'm observing numerous new findbug violations (introduced with the bump?) Is it okay to disable findbugs for now in OFP project? Is there any way to disable the same for the whole project?
Note: The findbug violations are mostly related to sl4j
gobinath no please do not disable FB! The slf4j related problems are really easy to fix, they are simple logging usage API mistakes - these are real logging bugs which make the logs less useful and therefore really should be fixed. They are easy to fix, see here: https://git.opendaylight.org/gerrit/#/c/76389/5..6
vorburger Have fixed the FB violations. I'm currently facing various test failures due to mockito migration probably. Many tests are failing with the following exception "org.mockito.exceptions.misusing.UnnecessaryStubbingException"
Checking on this I found that "strict" junit runner is default in mockito 2. The fix was to implicitly use "silent" junit runner. Is this fix fine or are we required to remove the unnecessary stubs(which could break some tests?)
I found the above solution here : https://support.intershop.com/kb/index.php/Display/2M8334#Guide-7.10MigrationMockito1toMockito2-MockitoJUnitRunner
They have some other useful info for mokito migration to 2
Yes, using silent mode is OK IMO for the migration. If you do use this though, please file a JIRA so you don’t forget to revisit the issue later — unused stubs mean that there are pieces of code which aren’t exercised by tests 
.
I decided not to use silent mode and removed all the redundant stubbings . But there seem to false positives in some cases. On removing some stubbings marked unnecessary I'm getting test failures. Is it ok to use lenient for such stubbings?
Yes, it’s OK — we can revisit the issue later, the important thing now is to get the MRI patch building and passing its tests.