Ashok, Erich and I talked briefly about this yesterday, but I was busy catching up after being OOO and was unable to close on this yesterday. The original intent was that IPv6 and the threading work were the last two items to go directly to master. I left Erich with the wrong understanding before being OOO for the week. This is complicated by the IPv6 work running longer than anticipated. I will close with Erich today on this matter. For larger bodies of work, we will still like smaller commits to feature branches for review, but we will not pull into master until the significant parts of the feature is complete. One point that I would like to make is that making a commit smaller does not mean just submitting code in parts. For example, pushing structures in one commit without logic or API makes for a meaningless review if the reviewer cannot determine how the structures will be used. On the other hand, pushing the entire API header (without implementation) in an early commit can be a good step for API review. If you chose this path, it helps if the commits comments are clear to desire. For example, API for thread model for review This commit includes the complete API definition for the new threading feature for review. Implementation is to follow based on feedback from this review and ... blah blah blah Signed-off-by: <howdy at hello.com> Regarding process; the wiki has a partial draft of the process proposal. It is not complete and I still need to document the process for major release and close all of the TODO. It also still needs review by ISG. However, it should help to understand the process that the ISG desires. Pat
From: ASHOKBABU CHANNA [mailto:[email protected]] Sent: Tuesday, June 23, 2015 1:57 AM To: Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org Subject: New branch and design policies Dear Pat, Could you clarify on the new branch policy? 1) As far as we know, new features should be committed and reviewed in new branches and only optimizations/bug fixes should go in master branch directly. We are not sure why the optimization/fixes( single thread /multi thread) are moved to new branch and IPV6 modifications such ashttps://gerrit.iotivity.org/gerrit/#/c/1081/ are merged to master mentioning it as high priority. Last 2 months, we resolved merge conflicts and expecting them to be merged . But now all of a sudden Erich is requesting for merge them in a new branch. 2) When we committed source , it's been requested to make smaller commits but now it's been asked to make larger commit which is impossible considering all platforms CA supports. And Design Policies: Some of the design decisions are taken internally without any discussion in developer list or mentioning it in dc tg conference calls which happens once in every two weeks. Here are the some comments in gerrit: Previous discussions on this are closed. Discussion was had, removed for good reason. https://gerrit.iotivity.org/gerrit/#/c/1081/42/resource/csdk/connectivity/api/cainterface.h Can we have the discussions open to theall developers instead of only to internal members? Regards, Ashok [cid:image001.gif at 01D0AD9F.1D1F72F0] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=929864819710bd59fd7a295317d579a4045f1de8fcabfe32a1889aa8efbbee4788d6974bd2f79a3cb3b9c254041823979dd130b31b023ef15296970253332b3707805447a154a46fcf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150623/bc731925/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150623/bc731925/attachment.gif>
