Hi Omar/Nathan
Let?s these requirements for release kept from the next release. To cut the feature earlier, CTT also should align together, but practically this is not easy work. Anyway I felt that IoTivity and OCF need more communication and coordination. Practically September timeline is what we can think about for final CTT. (I expect one or two months delay) mbedtls version will be updated by consequence patch just after release which might not change any API change. interopable issue is from the spec view, I think. To avoid people get confused, Let me post the release context with non-certifiable wording. Any suggestion will be welcomed except giving up this release. BR, Uze Choi From: Omar Maabreh [mailto:[email protected]] Sent: Tuesday, May 23, 2017 4:16 PM To: Heldt-Sheller, Nathan; uzchoi at samsung.com; iotivity-dev at lists.iotivity.org Subject: RE: [dev] Regarding IoTivity 1.3.0 release objective I am much more concerned about the two concerns that Nathan raises as well as their side effects. And, on the other hand, I see very little benefit to releasing 1.3. In my opinion for the release to be useful to anyone it needs to meet at least three requirements: 1. Meet basic certification for its feature set 2. Be interopable with previous releases 3. Be free of major security and quality issues Without the above three requirements I am not sure the release would be of use to anyone. Anyone doing interim work which didn?t have the above requirements could just take a snap of the 1.3-rel branch (or even master) and use that for their prototype or other work. They wouldn?t really need it to be labeled 1.3 as such. However, declaring a 1.3 release at this point would have negative consequences. For one, it would be a dead-on-arrival release, where even the features it is supposed to have wouldn?t really work properly. Companies trying to evaluate or use any of the new features can start building on incorrect foundation, and if/when such feature is fixed it may not work for them. For those companies or individuals evaluating IoTivity or OCF might conclude that the ecosystem is of low quality and not meant to interop with even previous releases and therefore untenable for their products. This would also undercut the goal of getting more contributors to the project. I do hear Uze?s concerns that by having the 1.3 release go past its scheduled release some of the resources that were originally meant to work may need to peel off to do other projects. However, declaring 1.3 done when it really isn?t, is not going to fix that problem. The release will still need to pass CTT and get its quality up, and declaring 1.3 done will, in my opinion, discourage others from joining the effort. Also it will create future headaches where it?ll set the precedent of having dead-on-arrival releases. Companies wanting to use IoTivity will need to figure out which releases are real and which ones are just half-baked. Figuring out which release will work with which other releases and to what degree will be a very difficult question to answer and would be a big headache for the ecosystem. In hindsight, I think it would have been better to cut some of the features earlier on. This would have made the CTT gap smaller, and would have prevented a bunch of the churn and bugs that came with introducing those features late. We do still have that lever to some degree though, where if some feature(s) proves to be too burdensome to pass we could disable it for the time being and move it to the next release. It will not solve the problem to the core, but might reduce the time and burden to some degree. Thanks, - Omar From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Heldt-Sheller, Nathan Sent: Monday, May 22, 2017 11:10 AM To: uzchoi at samsung.com; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Regarding IoTivity 1.3.0 release objective Hi Uze, Thanks for doing such as excellent job tracking all these issues and concerns and trying to hold to a successful schedule. In my opinion, as long as people are clear that 1.3.0 cannot be certified as either OIC 1.1 or as OCF 1.0 then it is okay to create the release, as a way to mark a relatively stable reference for OCF 1.0 feature preview, for purposes such as beginning vendor application integration etcetera. I do not object to creating a release, if it is useful for member companies? we want OCF to be adopted and be successful, after all! However I have two concerns: 1. This ?non-certifiable? 1.3.0 may be used as a basis for more than it is intended, and since it is not tested yet against complete 1.0 CTT, I am quite certain it contains issues and gaps with the Specifications and their required behavior, even if we haven?t identified them yet. Are we certain vendors will not ship OCF 1.3.0 based products and create interop issues in the field? 2. I also am concerned that with the Amsterdam schedule being so tight, we will skip ahead and start building Amsterdam on an incomplete foundation of 1.3.0, without first completing OCF 1.0 implementation (including all bug fixes and un-discovered feature gaps). That said I think if we commit to driving hard to close all remaining gaps and bugs with full OCF 1.0 CTT then I don?t see harm in releasing 1.3.0, again if it is useful to member companies to do so. But in my opinion, if we are not very disciplined, I think the above two concerns are likely to cause us trouble down the road. Sincerely, Nathan From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ??? Sent: Monday, May 22, 2017 10:35 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] Regarding IoTivity 1.3.0 release objective Hi All, Today I heard that there are lots of concern for 1.3.0 release in a hurry. But I'd like to share some background for this. Originally IoTivity has a plan to sync up with spec and certifiction schedule. However, there OCF 1.0 spec has been delayed and eventually this caused the misalignment with CTT final and IoTivity 1.3.0 release. >From the IoTivity side, we have scheduled it and some companies have a plan >with the original schedule. Developers in these company is not easy to contribute the effort beyond original plan due to the other task scheduled. I believe that keeping the original schedule in the IoTivity side is only way to extract the contribution these companies. Currently some major companies are mostly contributing the code, we cannot help considering this situation. If IoTivity is driven as paid project or work load is distributed across many companies/entities, we can be more flexible I think. Anyway, IoTivity 1.3.0 is not CTT compliant and not ready for certification, but it has full OCF1.0 features in code base. I think some month later, we can make the final CTT compliant version. I guess it is not feasible to make a CTT compliant version by one trial, without this imtermediate version(IoTivity 1.3.0). Please give any comment for my idea. BR, Uze Choi (IoTivity Releae function lead) --------- Original Message --------- Sender : ??? <uzchoi at samsung.com> Principal Engineer/IoT Lab(S/W??)/???? Date : 2017-05-22 21:45 (GMT+9) Title : [dev] [State update-4 for RC3] [Triage Meeting] RE: [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks After some patches are verified let me make the RC3 tag. Today Jenkins server is too slow. Please do not merge without my consent from now on?. BR, Uze Choi From: ??? (Uze Choi) [mailto:[email protected]] Sent: Monday, May 22, 2017 10:35 AM To: 'iotivity-dev at lists.iotivity.org' Cc: 'Agis, Ed'; 'Mitch Kettrick' Subject: [State update-3 for RC3] [Triage Meeting] RE: [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks Hi All, With the great help of Security People Nathan, Dan, Randeep, Dongik, Oleg, Andrii, Dmitriy and so on, Most of pending issues are resolved. However, there are still some code under the review, as of now. Please let them merged soon to make a RC3 tagging. BR, Uze Choi From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ??? Sent: Sunday, May 21, 2017 1:16 PM To: Heldt-Sheller, Nathan; Bell, Richard S; ???; iotivity-dev at lists.iotivity.org Cc: Agis, Ed; Mitch Kettrick Subject: Re: [dev] [State update-2 for RC3] [Triage Meeting] RE: [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks Hi Nathan, I believe Patches for these issues will be merged by this week. (I mean by this Sunday) Then release version can pass the current version CTT test case excluding issues to be resolved from CTT. And better to include following but not necessary to include below I believe. ? Bug IOT-1928 Update mbedtls version before 1.3 release ? Improvement IOT-1896 BR Uze Choi --------- Original Message --------- Sender : Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com> Date : 2017-05-21 08:12 (GMT+9) Title : RE: [dev] [State update-2 for RC3] [Triage Meeting] RE: [session2-Meeting minute]: [Triage CC schedule] [For 1.3 release RC2 ] list sharing and update request for some missing blocks Hi Uze, As an update, all known P1 Security Issues have either been resolved, or have pending patches in Gerrit review; see JIRA for updated status: All Open, In Progress, Assigned and Re-opened Issues with ?Security? tag, P1, and Fix In Version 1.3.0 We are waiting on code review and/or Jenkins for 7 of the 8 open issues. The mbedTLS update issue, you already known about. However it should be noted that there are likely many outstanding issues other than these that will prevent OCF 1.0 certification. I understand it is your intention to release 1.3.0 without passing complete CTT, but I wanted to be 100% clear that there will almost surely be other certification blocking issues discovered as CTT and IoTivity bugs are fixed and more of the TCs are running. I hope the intention is to release again when complete CTT is passing. Summary copy/paste from JIRA: ? Bug IOT-2293 [Security] /oic/sec/acl2 resource is being updated by payload for /oic/sec/acl resource ? Bug IOT-2292 [Security] 'creds->credusage' property of /oic/sec/cred resource is of string type, expected is array of string in OCF1.0 ? Bug IOT-2281 [Security] /oic/sec/amacl resource is responding for GET request, but not for POST ? Bug IOT-2280 [Security] /oic/sec/doxm resource unable to update rowneruuid ? Bug IOT-2271 provisioningclient fails to discover sampleserver_randompin, when using default ACEs ? Bug IOT-2258 OCCreateResource() must allow Secure *and* Unsecure "ep" ? Bug IOT-1928 Update mbedtls version before 1.3 release ? Improvement IOT-1896 Implement privacy mitigation approach for unique identifiers Thanks, Nathan _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&data=02%7C01%7Comarm%40microsoft.com%7C27ac778b9da34e3e15ca08d4a13dc66f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636310734108597599&sdata=5wMUXpyqbDrteyi5zJz7vse6%2FzyAfCwMsSBd9s7O8PY%3D&reserved=0> <http://ext.samsung.net/mail/ext/v1/external/status/update?userid=uzchoi&do=bWFpbElEPTIwMTcwNTIyMTczNTE0ZXBjbXMxcDZlZjBiOGY2ZjkxM2YxODhjZjNiOTNmMDk2OTc4NWFiMyZyZWNpcGllbnRBZGRyZXNzPWlvdGl2aXR5LWRldkBsaXN0cy5pb3Rpdml0eS5vcmc_> -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170523/fffa959c/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 78387 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170523/fffa959c/attachment.png>
