When it comes to fully supported platform, IoTivity release officially covers Ubuntu, Tizen, Android, Arduino platforms. This means QA team verifies IoTivity from each platform.
However, this is time to reconsider the platform coverage. Regarding Arduino, not easy to manipulate the IoTivity working for the multicast issue and other transport support is also challenging. Furthermore, we also need to think about other popular platform such as Windows, iOS together. If there are no more drastic need for Arduino, it will be better to exclude its support and instead include the Windows platform from upcoming Sep. release. Regarding Arduino, any feedback will be welcomed. BR, Uze Choi From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of Dave Thaler via iotivity-dev Sent: Thursday, July 07, 2016 7:56 AM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] New Project and maintainer in IoTivity Here?s an elaboration of my views and recommendations? One issue I have is what qualifies as a "supported platform". In the AllJoyn open source project, we made a clear distinction (as far as claimed level of support) between a ?fully supported? platform, and an ?experimental? one (those aren't the labels they use though). A ?fully supported? platform is one where all features work, and a new feature should not be committed to master unless it works (and tests exist and pass) with *all* of them. You can commit a new feature if it works with all such platforms, and may or may not work with any ?experimental? platforms. And there's a process to make a platform be a fully-supported platform, which involves having a sub-maintainer signed up for it, working sample code, working unit tests for all fully-supported features, etc. I have had good experience with that process, and it seems to me that IoTivity is lacking in process or at least clear explanations of such process and platform expectations (let me know if there is such process/explanation, since I haven?t found one on any IoTivity web page or wiki page). As the primary maintainer, I would push the ISG for such a rule, or something similar. Any platform without a specific sub-maintainer is by definition not a fully supported platform in the sense above. Anyone wanting a platform to be on the fully supported list needs to pony up a sub-maintainer. Lacking a sub-maintainer for a platform, any code (new or existing) is able to be disabled for that platform if there is an issue with it. So for example if there is no iOS sub-maintainer then it's not a fully supported platform and any iOS issues might be dealt with by disabling code on that platform until the code compiles, or by disabling any tests on that platform that fail when code does compile. I am volunteering for two things: First, I?m volunteering for the overall maintainer, to institute such policies as are agreed on and maintain a Platform Abstraction Layer (PAL) architecture into which platform-specific code can be placed (the latter may take a while and will need incremental steps, of which work we did in the windows-port branch was one step). My thoughts on the PAL architecture are that the end goal should be to converge on the autoconfig-style approach like other open source projects use. The end goal would have a few characteristics: 1) No platform-specific defines appear on the command line, but only appear inside config.h 2) #include ?config.h? always occurs before any #ifdef?s in code. 3) Platform_features.h gets replaced by config.h stuff 4) A few platforms (as close to 0 as possible) have their own config.h variants when the toolchain cannot generate config.h? the master config.h might have something like (pseudocode) If OS is (say) tizen Include config_tizen.h Else Rest of normal config.h stuff 5) Platform-specific ifdefs should ideally not appear in any generic code, but be confined to code inside a PAL layer. We did some of that in the windows-port branch for example, where we created Windows versions of pthreads, usleep, etc. so as to remove ifdefs throughout normal code. Secondm I am also volunteering for Windows sub-maintainer but not sub- maintainer of any other platform. Dave From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of Dave Thaler via iotivity-dev Sent: Tuesday, July 5, 2016 6:28 PM To: ???(Uze Choi) <uzchoi at samsung.com>; iotivity-dev at lists.iotivity.org Subject: Re: [dev] New Project and maintainer in IoTivity In the 6/10 meeting, I volunteered for ?platform extension? (but not for sub-maintainer of platforms other than Windows), at least for the near term. That offer still stands. I would be looking for others to volunteer for sub-maintainers for other specific platforms. I don?t expect any single person to exist who is an expert on all platforms. From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of ???(Uze Choi) Sent: Monday, July 4, 2016 1:00 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] New Project and maintainer in IoTivity Please let me make it clear for new projects and maintainers. >From the ISG, Projects have been approved for following three but maintainers is also announced for two. - Platform extension: ??? - UPnP bridge: Rick Bell <richard.s.bell at intel.com> - node.js : Poussa, Sakari <sakari.poussa at intel.com> ?Platform extension? project is responsible for All platform extension including Windows/Android/iOS and so on. Maintainer of this project should take care of all these stuffs and can place multiple sub-maintainers for each specific platform where maintainer does not have detail knowledge. There were a couple of times for this explanation thru email thread why ISG approved this project as like it. This is time to get the candidate for this project. Dave already want to be the Windows port maintainer only, but maintainer for this project is required to cover more scope. Once maintainer approved, +2 in Gerrit will be granted. BR, Uze Choi From: Bell, Richard S [mailto:[email protected]] Sent: Wednesday, June 29, 2016 3:36 AM To: uzchoi at samsung.com; iotivity-dev at lists.iotivity.org Subject: RE: [dev] Review request: merge windows-port to master Uze, Thanks letting me know that UPnP Bridge have approved in ISG meeting. I will update https://wiki.iotivity.org/projects_and_functions with UPnP Bridge I assume there was no the requirement for separate project. How to handle build process for separate project and releases with various iotivity releases.. Thanks, Rick Bell OTC UPnP/DLNA Software Team Intel Corporation (503) 712 8209 From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of ??? Sent: Tuesday, June 28, 2016 9:48 AM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Review request: merge windows-port to master >From ISG, platform extension project is approved which covers the Android, Windows and future targeting platform such as iOS. As a maintainer model, main maintainer and sub maintainer concept as below is proposed but upto maintainer's decision. The main maintainer lead the common structure across multi platforms, sub maintainer can cover each platform specific. Once ISG requests the maintainer offering, we can propose the maintainer. At the same time, UPnP bridge and node.js project are also approved in ISG meeting. BR, Uze Choi --------- Original Message --------- Sender : Thiago Macieira <thiago.macieira at intel.com> Date : 2016-06-29 01:19 (GMT+9) Title : Re: [dev] Review request: merge windows-port to master We will post the minutes later, but yes, the project structure that Uze presented was approved. We now have a framework for maintainership of the port. Please proceed with reviewing the branch merge. On terca-feira, 28 de junho de 2016 09:11:31 PDT ??? wrote: > Although I can't join this ISG meeting, thiago or uze can let you know some > progress after this ISG meeting in this week. > > BR > > Jinguk Jeong > > > --------- Original Message --------- > Sender : Jon A. Cruz <jon at joncruz.org> > Date : 2016-06-28 17:06 (GMT+9) > Title : Re: [dev] Review request: merge windows-port to master > > On Tue, Jun 7, 2016, at 05:59 PM, ??? wrote: > Dear Antler, > > ISG members are discussing about project policy, now. > Currently, it is not determined who will be a maintainer, which project > structure will be the best for supporting several platforms, ... Plz wait > some more time before merging to master. > > BR > > Jinguk Jeong > > Has there been any progress on this front? Other changes are starting to get > backed up waiting on this, as we are accumulating more and more engineering > debt the longer we wait. > -- > Jon A. Cruz > jon at joncruz.org > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev <http://v70ext.samsung.net/mail/ext/v1/external/status/update?userid=uzchoi&; do=bWFpbElEPTIwMTYwNjI4MTY0NzMyZXBjbXMxcDJjYjczNTFmYjgyMGVhMGY0YjAyNTc0NDgzZ TZlMzhjZCZyZWNpcGllbnRBZGRyZXNzPWlvdGl2aXR5LWRldkBsaXN0cy5pb3Rpdml0eS5vcmc_> -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160707/a4fd0d7a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33527 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160707/a4fd0d7a/attachment.png>
