#opendaylight-meeting: MD-SAL interest call

Meeting summary

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

Action items

1. (none)

People present (lines said)

1. tbachman (64)
2. devinavery (6)
3. odl_meetbot (4)