16:01:17 <devinavery> #startmeeting MD-SAL interest call
16:01:17 <odl_meetbot> Meeting started Tue Mar 17 16:01:17 2015 UTC.  The chair is devinavery. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:01:17 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:17 <odl_meetbot> The meeting name has been set to 'md_sal_interest_call'
16:05:29 <devinavery> #chair tbachman
16:05:29 <odl_meetbot> Current chairs: devinavery tbachman
16:05:41 <tbachman> devinavery: if you have the host key we can record as well
16:06:21 <tbachman> #info devinavery says last week we discussed doing a review of changes in the works, in order to keep track of what’s going on as well as bring others into the conversation
16:06:26 * tbachman goes off to get some links...
16:07:01 <tbachman> #link https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call Weekly call, with agenda
16:07:42 <tbachman> #link https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Queries shows changes to the controller
16:07:54 <tbachman> #info edwarnicke asks if there’s a way to remove “excessively stale” patches
16:08:08 <tbachman> #info devinavery says we could add some constraint, such as older than 30 days
16:08:57 <tbachman> #info devinavery says the first goal is to get a sense of what changes are going into the controller core
16:09:24 <tbachman> #info devinavery asks if there are any other projects besides controller and yangtools that are needed
16:09:35 * tbachman hears colindixon and edwarnicke cross-talk
16:09:53 <tbachman> #info colindixon says we could add AAA
16:10:33 <tbachman> #info edwarnicke says he’s a bit concerned about scope creeping beyond the capacity to influence (e.g. we may not have any AAA committers here)
16:10:49 <tbachman> #info colindixon says that’s where we may want to intentionally increase the scope
16:11:17 <tbachman> #info edwarnicke says at some point this stops becoming just an MD-SAL call, and is a different call (not a bad thing, just different)
16:11:52 <tbachman> #info devinavery says we may also want to collect NETCONF and MD-SAL breakouts here
16:13:32 <tbachman> #info devinavery says one example was in Helium, POSTing on RESTCONF wouldn’t wait for the data store
16:14:20 <tbachman> #info devinavery says in yangtools, the orderby clause was broken for SFC, which was fixed
16:14:41 <tbachman> #info colindixon asks about the ordered by fix
16:14:50 * tbachman wonders why colindixon sounds like he’s at the bottom of a hole
16:15:33 <tbachman> #info ttkacik says the orderedby statement is honored by the data store, but the problem is that configuration data requires you to have a key
16:15:52 <tbachman> #info ttkacik says the orderedby was to show that the data was reordered after the PUT
16:16:09 <tbachman> #info ttkacik says the MD-SAL will use less-efficient data structures, but will preserve the ordering
16:16:16 <tbachman> #info colindixon asks why it’s less efficient
16:16:45 <tbachman> #info rovarga says simply b/c you have to use a linked hashmap and not a hashmap — you need an iterable collection that guides the iteration ordered
16:17:02 <tbachman> #info colindixon says you need one extra pointer per object — it’s about a 2% hit
16:17:33 <tbachman> #info rovarga says there are no just pointers in java, so it has to go somewhere (objects have a minimum size of 12 bytes); with collections that are millions of entries long, this makes a differenc
16:18:35 <tbachman> #info rovarga says if you say a particular list is ordered by, then a different backing class is used to store those entries — a linked hash map
16:18:49 <tbachman> #info rovarga says a trie or hash map won’t preserve the order
16:26:52 * tbachman had a power-outage…. back
16:26:58 <tbachman> logging back in to webex
16:27:29 <devinavery> #info  discussing patch size - do we have any experience on how many lines is too many
16:28:34 <devinavery> #info no consensus on if line counts are useful or not...
16:28:42 * tbachman is back
16:28:58 <tbachman> #info ttkacik says they aren’t one-to-one — multiple patch sets can be attached to the bug
16:29:03 <devinavery> #info proposal that bug should have a bug in "large line count" patches
16:29:10 <devinavery> Take it Thomas - thanks
16:29:12 <tbachman> np
16:29:44 <tbachman> #info devinavery asks if it’s fair to say that even if it’s the same bug ID, it’s a bug ID in the commit message — is it fair to say we encourage this in bug commit messages?
16:30:03 <tbachman> #info edwarnicke says it’s a good idea to have bug IDs in commit messages in general
16:30:22 <tbachman> #info edwarnicke asks what is the purpose of the attaching bug
16:31:02 <tbachman> #info ttkacik says there are two types: some that are mostly about the functionality, which should have bugs attached; and others that only deal with source code quality
16:31:12 <tbachman> #info ttkacik says it doesn’t make sense to create bugs for the small issues
16:31:49 <tbachman> #info rovarga seconds that — recalls a number of “drive-by’s” like this. Isn’t sure that forcing this for all patches isn’t the right way
16:32:26 <tbachman> #info edwarnicke says sonar has been very useful — encourages folks to go to sonar and start working through the code-quality complaints
16:33:16 <tbachman> #info colindixon says we’re looking for things that help us in practice, that are “probably should” guidelines
16:33:48 <tbachman> #info devinavery says if we’re changing functionality, a bug should exist — helps us understand the old behavior, desired behavior, and potentially how we’re going to fix it — asks if anyone objects to this
16:34:44 <tbachman> #info devinavery says it’s up to the committers to see if they understand the reason behind the change — if they don’t understand why it’s necessary, they can request more information, and this is where a bug is helpful
16:35:01 <tbachman> #info rovarga says you have to be careful with that guidance
16:35:35 <tbachman> #info devinavery says part of the goal is to have others besides committers review the code — the committers also need to ensure the rest of the community understands what’s changing
16:36:08 <tbachman> #info rovarga says explaining things to the general public means that if someone doesn’t get it, you can’t merge the change — have to be careful with these kinds of statements
16:36:35 <tbachman> #info edwarnicke says he believes devinavery is saying something different — he’s saying that it’s helpful to us to grow the community if we make some effort to help others who are trying to get involved
16:36:56 <tbachman> #info devinavery says yes — also a historical dimension to this — helps folks who come later to understand
16:37:35 <tbachman> #info devinavery says that’s one of the reasons for a bug — isn’t to gate the merge, but to help people understand them
16:37:48 <tbachman> #info rovarga says he’d encourage using better commit messages first, then using bugs
16:38:29 <tbachman> #info devinavery says yes — the commit message is important; but bug IDs can help as a reference for very long descriptions that aren’t appropriate for commit messages
16:43:09 * tbachman returns from narcoleptic fit
16:43:40 <tbachman> #info edwarnicke asks if there are known outstanding issues with restconf — is interested in moving with the clustering switchover
16:43:51 <tbachman> #info ttkacik says he needs to verify his patch fixes the downstream projects
16:44:10 <tbachman> #info edwarnicke asks if we’ve come up with a smarter way of informing folks of changes of this nature
16:44:52 <tbachman> #info devinavery says we may have to follow up on this in a subsequent call
16:46:13 <tbachman> #info ttkacik says the patches for Bug 2362 changes constraints validation from compulsory to optional
16:47:10 <tbachman> #info colindixon says if this is going to slow controller down by 3-4 weeks, then we can talk about this
16:47:35 * tbachman hears colindixon doing daddy day care
16:48:35 <tbachman> #info edwarnicke asks if there’s a more effective way of communicating changes that break everything
16:49:21 <tbachman> #info colindixon says no, but he feels the right approach is to have both a static place to log them, and email release, and cross-link the two
16:49:49 <tbachman> #info colindixon says he has an email (either already sent, or in his outbox) on this topic
16:50:28 <tbachman> #info devinavery says next week will be a presentation on the message bus
16:50:32 <tbachman> #endmeeting