17:30:56 #startmeeting networking_lib 17:30:57 Meeting started Wed Jul 20 17:30:56 2016 UTC and is due to finish in 60 minutes. The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:31:00 The meeting name has been set to 'networking_lib' 17:31:11 #topic Announcements 17:31:20 I'm out next Wednesday. Any volunteers to chair the meeting? 17:31:45 I’ve never done, but am happy to try 17:31:52 sure. 17:32:00 #action boden to chair next week's meeting 17:32:06 #topic What changes are applicable to release notes? 17:32:31 what do we have for release notes today? 17:33:22 I’m thinking none, but am trying to verify 17:33:25 * HenryG pops in fashionably late 17:33:43 do we need them for a developer library? likely, but i'm asking anyway. 17:34:15 I think it would be nice for changes in the api contract 17:34:29 Most of them will be for additions, I guess 17:34:40 what do we think of the proposal for all interface changes require a reno? 17:34:42 we talked about generating a changed API summary, IMHO that would suffice 17:35:55 That might work. We could generate a reno from that when tagging a release. 17:36:18 I’m skipping ahead in topics, but its releated… #link http://paste.openstack.org/show/526626/ 17:36:21 the auto-generation would be plenty for my tastes, personally. 17:36:21 is a sample 17:36:51 LGTM 17:37:18 #action need to add lib release action to add a reno with auto-generated api differences 17:37:37 #link http://paste.openstack.org/show/526626/ 17:37:54 moving on 17:38:01 #topic Does all public code needs doc string and perhaps adding a hacking check for it? 17:38:59 my vote is yes, but we are adding barriers to moving code (new unit tests, new docstrings) 17:39:08 IMO we should encourage it but not dictate it 17:40:05 fair enough; we can dev-ref that public api “should” be documented, but no hacking check 17:40:15 +1 17:40:17 I guess I’ll stop -1ing for missing docs :) 17:40:29 can hacking checks be warnings? cleaning up the warnings might be good ATC fodder. 17:40:49 I was thinking that too 17:41:15 I can follow-up on if a check can warn 17:41:41 Sounds good 17:41:45 #action boden to check on if hacking checks can be warnings 17:41:57 #topic public api report tool 17:42:02 boden, take it away 17:42:15 so we just saw a sample of its output 17:42:23 It seems to work well 17:42:27 question is; do we care how pretty/robust this ‘tool’ is? 17:42:45 e.g. should I go off and make it nice 17:42:46 I am inclined to approve it and we can fix issues as they arise 17:42:58 i think what you had looked great for our purposes. likely don't need to spew the unchanged section. 17:43:13 dougwig: agree 17:43:25 I have a few TODOs I want to clean up in that code 17:43:27 It's not going to break any production code, so we can carry it with bugs and iterate 17:43:29 then I’ll submit for review 17:43:41 good. 17:43:45 do you think it should be run as part of pep8? or may a standalone tox target for it? 17:43:46 #topic Open discussion 17:43:50 anything else for today? 17:43:59 sorry: I had 1 more question ^ 17:44:13 boden: I vote for standalone tox target 17:44:34 works for me 17:44:44 boden: I think it doesn't need to run in the gate 17:44:56 agreed 17:45:46 nothing else from me 17:45:54 Regarding base DB stuff, I need dougwig and kevinbenton to lay eyes on https://review.openstack.org/339875 17:46:34 ack 17:46:43 HenryG: disregard my doc questions as per our discussion today on docs :) 17:47:01 boden: ack 17:47:47 ok, let's blast out of here and do some reviews. 17:47:50 thanks all 17:47:52 #endmeeting