16:58:43 <rgoulding> #startmeeting kernel projects 16:58:43 <odl_meetbot> Meeting started Tue Jan 9 16:58:43 2018 UTC. The chair is rgoulding. Information about MeetBot at http://ci.openstack.org/meetbot.html. 16:58:43 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:58:43 <odl_meetbot> The meeting name has been set to 'kernel_projects' 16:58:53 <rgoulding> #topic agenda bashing 16:59:00 <rgoulding> #link https://wiki.opendaylight.org/view/ODL_Root_Parent:BigBumpOfJan2018 16:59:07 <rgoulding> #info AsyncWriteTransaction submit() with @CheckReturnValue 17:00:36 <vorburger> rgoulding: FYI I'll join in 2' 17:00:46 <rgoulding> sounds good! 17:04:07 <rgoulding> #topic BigBumpOfJan2018 17:04:17 <rgoulding> #link https://wiki.opendaylight.org/view/ODL_Root_Parent:BigBumpOfJan2018 17:07:17 <rgoulding> #info kernel patches have been updated already 17:07:32 <rgoulding> #info many of the others including netvirt, infrautils, genius, etc. have been updated to use 3.0.2 17:07:37 <rgoulding> #info more testing is needed 17:08:26 <rgoulding> #info other patches need to be ammended to utilize 3.0.2 instead of 3.0.2-SNAPSHOT 17:10:56 <rgoulding> #info skitt, if CSIT passes and results aren’t too scary, perhaps that is enough to get releng to merge them? 17:11:08 <rgoulding> #info the initial plan was to kick everyone out and then bring back in 17:11:16 <rgoulding> #info Thursday TSC call will make the call whether to go/no-go 17:12:22 <rgoulding> #info rovarga says it might be better to just do it one by one 17:12:42 <rgoulding> #info i.e., wait until one merge job finishes and publishes artifacts, then recheck the next, and so-on 17:18:41 <rgoulding> #info Will 3.0.2 be the final version? 17:18:56 <rgoulding> #info the opinion is that this is the version we will release with unless we find something that requries a new revision 17:19:46 <rgoulding> #info if we do need a new version, we should be able to do this easier by just bumping the version to 3.0.3 in integration/distribution and inheriting the newer version in the runtime since we use version ranges 17:21:01 <rgoulding> #info rovarga if this transition is smooth and done in a reasonable timeframe, then we can discuss whether it makes sense to roll out 2.0.1 of yangtools to get the fixes in that 17:21:19 <rgoulding> #info if not, we will just punt to SR1 and be done 17:31:44 <rgoulding> #info vorburger states that the timeline is tight 17:32:21 <rgoulding> #info LuisGomez says that there will need to be a patch to remove non-tested patches 17:32:35 <rgoulding> #info vorburger is there a fallback plan? 17:32:54 <rgoulding> #info skitt the fallback would be odlparent 2.0.6 and what would be the case in yangtools? 17:33:14 <rgoulding> #info rovarga only option would be to use yangtools 1.2.1 which was used in Nitrogen SR1 17:33:36 <rgoulding> #info skitt what would the consequences of that be to end users in oxygen? 17:34:00 <rgoulding> #info rovarga there is a clustering bug reported in live environments that could not be fixed without yangtools 2.0.0 17:34:07 <rgoulding> #info related to running clusters across timezones 17:34:18 <rgoulding> #info it would be painful for downstreams 17:35:33 <rgoulding> #info the expectation is that fallout from this will be minor, since a lot of unit tests are passing 17:37:50 <rgoulding> #info vorburger states that it now takes much much longer to make changes in odlparent now to get changes in 17:38:02 <rgoulding> #info rovarga you either get isolation or integratability 17:38:07 <rgoulding> #info there isn’t really a middle ground 17:38:55 <rgoulding> #info rovarga at some point the core needs to stop churning releases and pushing on downstreams to track them 17:39:23 <rgoulding> #info vorburger doesn’t have a solution persay, but he does wnat to point out that it takes a long time to fix even small things. Things have slowed down to integrate things in odlparent 17:39:31 <rgoulding> #info vorburger asks if there are better solutions? 17:41:37 <rgoulding> #info skitt there is friction that arises since upgrades all have different constraints. for example, we could fix bugs quickly in karaf and only bump affected downstream projects. But since we have everything bunched together, it is more involved to adapt. The advantage to version ranges is that we could achieve a lot of this much more quickly 17:41:45 <rgoulding> #info perhaps we will need to split odlparent up somehow 17:43:14 <rgoulding> #info skitt regarding development velocity there is some rule / best practice (written down somewhere) stating we develop things in a downstream and then once it becomes more useful we push it up. if you stick to that then assuming nothing upstream blocks you, then you can still have good velcoity. Starting things where they will ultimately end up (i.e., odlparent), that will slow you down. 17:43:33 <rgoulding> #info the idea is to start local, then move upwards 17:43:59 <rgoulding> #info rovarga not sure if we will be able to make version ranges completely work 17:44:25 <rgoulding> #info rovaraga what if we bump to karaf to 4.1.4 in odlparent 3.0.3, which also bumps jetty then what happens in the various situations? 17:44:33 <rgoulding> #info i.e., jetty causes incompatibilities but karaf doesnt 17:45:03 <rgoulding> #info other projects have stated they arent really doing semver (netty) 17:45:36 <rgoulding> #info some upstreams don’t necessarily comply to non-breaking API changes, whcih makes it particularly hard to upgrade 17:45:51 <rgoulding> #info there is a lot of work that could be done on the odlparent side that could be done to pre-validate, but that might be more useful in int/dist 17:46:25 <rgoulding> #info skitt for checkstyle, we should have checkstyle snippets to get to the point where only certain parts can be enforced in downstreams as opposted to all or none 17:46:48 <rgoulding> #info skitt temporarily, we could have different projects using different versions of odlparent 17:47:09 <rgoulding> #info i.e., if there is somethign missing in the karaf configuration 17:47:43 <rgoulding> #info skitt points out that this means being very careful about what is merged to odlparent 17:47:59 <rgoulding> #info rovarga, which runs contratry to quicker velocity desires 17:48:38 <rgoulding> #info run continuous deployment will allow us to see an automated scripted release with each patch. We don’t have all the scripting or build infra to get there yet. 17:49:06 <rgoulding> #info the distribution-check does some of this, but it depends on autorelease 17:52:21 <rgoulding> #info LuisGomez something we are missing for sure is an autorelease job that builds all the projects with latest version of odlparent/yangtools to produce some distribution that we can pass to CSIT 17:52:43 <LuisGomez> #link https://jira.opendaylight.org/projects/RELENG/issues/RELENG-69 17:53:19 <rgoulding> #info rovarga it should be spinning a release for each project in the dependency order, and running CSIT against the staged artifacts, and if the projects CSIT passes, then it should be good to release 17:54:25 <rgoulding> #info rovarga the thing is that if it is autorelease, then it takes half a day and any sort of glitch or failure is a show stopper for seeing useful results 17:56:09 <rgoulding> #info LuisGomez this may be too expensive though (per project) 17:56:55 <rgoulding> #info LuisGomez there will be a lot of infra load. Maybe it makes more sense to do it with one particular case (i.e., netvirt which has a lot of CSIT) then we have some confidence of whether the change is good 17:57:46 <rgoulding> #topic AsyncWriteTransaction submit() with @CheckReturnValue 17:57:59 <rgoulding> #link https://git.opendaylight.org/gerrit/#/c/66360/ 17:58:11 <rgoulding> #link https://git.opendaylight.org/gerrit/#/c/66361/ 17:58:14 <rgoulding> will this hit Oxygen? 17:58:45 <rgoulding> #info tpantelis this is an API change and we are beyond API freeze now 17:59:47 <rgoulding> #info API freeze is not only an ODL internal thing, but also the downstreams that we don’t know about 18:00:06 <rgoulding> #info while it gives us a feeling of what it will do andaffect in our own release, it doesn’t address the fact that we dont’ know what is happening downstream 18:02:04 <rgoulding> #topic slf4j code quality checks with checkstyle-odl-checks VS findbugs-slf4j.. because of Eclipse IDE integration issue, I propose to: 18:02:16 <rgoulding> #link https://git.opendaylight.org/gerrit/#/c/66449/ 18:03:37 <rgoulding> #info compare the checks that are provided by both 18:04:56 <rgoulding> #info rovarga doesn’t want to get rid of the checkstyle ones if they add anything on top of findbugs one 18:05:02 <rgoulding> #info we can keep in cs too 18:05:16 <rgoulding> #info vorburger is much less motivated to get the CS patches in 18:07:25 <rgoulding> #topic FYI error-prone now adopted in infrautils, with custom tuned config. If time, may try to use infrautils parent e.g. in genius. 18:07:54 <rgoulding> #info vorburger spent time to tune a config for this and has switched infrautils to enforce 18:10:12 <rgoulding> #info rovarga enabling error-prone breaks some valid code 18:10:20 <rgoulding> #info rovarga something with type inferences/generics 18:10:41 <rgoulding> #info vorburger this project is very active and what might have broken in the past might be fixed now 18:13:03 <rgoulding> #endmeeting