=========================================== #opendaylight-meeting: MD-SAL interest call =========================================== Meeting started by devinavery at 16:01:17 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-meeting/2015/md_sal_interest_call/opendaylight-meeting-md_sal_interest_call.2015-03-17-16.01.log.html . Meeting summary --------------- * 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 (tbachman, 16:06:21) * LINK: https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call Weekly call, with agenda (tbachman, 16:07:01) * LINK: https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Queries shows changes to the controller (tbachman, 16:07:42) * edwarnicke asks if there’s a way to remove “excessively stale” patches (tbachman, 16:07:54) * devinavery says we could add some constraint, such as older than 30 days (tbachman, 16:08:08) * devinavery says the first goal is to get a sense of what changes are going into the controller core (tbachman, 16:08:57) * devinavery asks if there are any other projects besides controller and yangtools that are needed (tbachman, 16:09:24) * colindixon says we could add AAA (tbachman, 16:09:53) * 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) (tbachman, 16:10:33) * colindixon says that’s where we may want to intentionally increase the scope (tbachman, 16:10:49) * edwarnicke says at some point this stops becoming just an MD-SAL call, and is a different call (not a bad thing, just different) (tbachman, 16:11:17) * devinavery says we may also want to collect NETCONF and MD-SAL breakouts here (tbachman, 16:11:52) * devinavery says one example was in Helium, POSTing on RESTCONF wouldn’t wait for the data store (tbachman, 16:13:32) * devinavery says in yangtools, the orderby clause was broken for SFC, which was fixed (tbachman, 16:14:20) * colindixon asks about the ordered by fix (tbachman, 16:14:41) * ttkacik says the orderedby statement is honored by the data store, but the problem is that configuration data requires you to have a key (tbachman, 16:15:33) * ttkacik says the orderedby was to show that the data was reordered after the PUT (tbachman, 16:15:52) * ttkacik says the MD-SAL will use less-efficient data structures, but will preserve the ordering (tbachman, 16:16:09) * colindixon asks why it’s less efficient (tbachman, 16:16:16) * 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 (tbachman, 16:16:45) * colindixon says you need one extra pointer per object — it’s about a 2% hit (tbachman, 16:17:02) * 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 (tbachman, 16:17:33) * 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 (tbachman, 16:18:35) * rovarga says a trie or hash map won’t preserve the order (tbachman, 16:18:49) * discussing patch size - do we have any experience on how many lines is too many (devinavery, 16:27:29) * no consensus on if line counts are useful or not... (devinavery, 16:28:34) * ttkacik says they aren’t one-to-one — multiple patch sets can be attached to the bug (tbachman, 16:28:58) * proposal that bug should have a bug in "large line count" patches (devinavery, 16:29:03) * 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? (tbachman, 16:29:44) * edwarnicke says it’s a good idea to have bug IDs in commit messages in general (tbachman, 16:30:03) * edwarnicke asks what is the purpose of the attaching bug (tbachman, 16:30:22) * 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 (tbachman, 16:31:02) * ttkacik says it doesn’t make sense to create bugs for the small issues (tbachman, 16:31:12) * 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 (tbachman, 16:31:49) * edwarnicke says sonar has been very useful — encourages folks to go to sonar and start working through the code-quality complaints (tbachman, 16:32:26) * colindixon says we’re looking for things that help us in practice, that are “probably should” guidelines (tbachman, 16:33:16) * 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 (tbachman, 16:33:48) * 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 (tbachman, 16:34:44) * rovarga says you have to be careful with that guidance (tbachman, 16:35:01) * 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 (tbachman, 16:35:35) * 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 (tbachman, 16:36:08) * 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 (tbachman, 16:36:35) * devinavery says yes — also a historical dimension to this — helps folks who come later to understand (tbachman, 16:36:56) * devinavery says that’s one of the reasons for a bug — isn’t to gate the merge, but to help people understand them (tbachman, 16:37:35) * rovarga says he’d encourage using better commit messages first, then using bugs (tbachman, 16:37:48) * 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 (tbachman, 16:38:29) * edwarnicke asks if there are known outstanding issues with restconf — is interested in moving with the clustering switchover (tbachman, 16:43:40) * ttkacik says he needs to verify his patch fixes the downstream projects (tbachman, 16:43:51) * edwarnicke asks if we’ve come up with a smarter way of informing folks of changes of this nature (tbachman, 16:44:10) * devinavery says we may have to follow up on this in a subsequent call (tbachman, 16:44:52) * ttkacik says the patches for Bug 2362 changes constraints validation from compulsory to optional (tbachman, 16:46:13) * colindixon says if this is going to slow controller down by 3-4 weeks, then we can talk about this (tbachman, 16:47:10) * edwarnicke asks if there’s a more effective way of communicating changes that break everything (tbachman, 16:48:35) * 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 (tbachman, 16:49:21) * colindixon says he has an email (either already sent, or in his outbox) on this topic (tbachman, 16:49:49) * devinavery says next week will be a presentation on the message bus (tbachman, 16:50:28) Meeting ended at 16:50:32 UTC. People present (lines said) --------------------------- * tbachman (64) * devinavery (6) * odl_meetbot (4) Generated by `MeetBot`_ 0.1.4