Markus, I understand and I am leaving it with Uze to drive that issue.
Pat From: Markus Jung [mailto:[email protected]] Sent: Thursday, January 29, 2015 7:48 PM To: Lankswert, Patrick; Uze Choi; iotivity-dev at lists.iotivity.org Subject: Re: Re: [dev] Control Manager Hello Pat, I think what Uze wants to say is that the generated code is currently not the main issue for not pulling the control-manager branch into master. The control manager consists of a very valuable framework and useful components for IoTivity, but it is mainly aligned to SHP (resource model, HTTP REST interface, ...). Further integration work into the overall IoTivity architecture and also alginment with the OIC specification is required, before it can be pulled into master. Best regards, Markus ------- Original Message ------- Sender : Lankswert, Patrick<patrick.lankswert at intel.com <mailto:patrick.lankswert at intel.com> > Date : Jan 30, 2015 01:50 (GMT+09:00) Title : Re: [dev] Control Manager Uze, If you are saying that generated code should not be committed to the repository if the generator is contributed, I agree with you. For example, if we had a tool that generated C++ and Java from an XML file description, then the only two things that should be in the repository are the source for the tool (unless shared in a different repository) and the XML file since the generated Java and C++ code are intermediate artifacts of the build process and not source. I leave it to you as the services maintainer to decide if/when the control-manager should be pulled into master. If you decide to pull it into master, if you want some help, I would be happy to assist wherever I can in review or git operations. This discussion has been helpful to me to understand what are the policies for contributions like control-manager. Pat -----Original Message----- From: ???(Uze Choi) [mailto:[email protected]] Sent: Wednesday, January 28, 2015 7:46 PM To: Lankswert, Patrick; iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: RE: [dev] Control Manager Hi Pat, As I mentioned several times, Due to not code generation issue but resource model alignment issue, I would not merge the Control Manager Code into master now. Then, I think this discussion using Control Manager is not appropriate to do some action. If we are defining the general criteria how to handle generated code from tool, Thiago's opinion is a little bit strange because generated code should not be accepted even if tool is contributed due to code sync issue. BR, Uze Choi -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org <mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev- bounces at lists.iotivity.org <mailto:[email protected]> ] On Behalf Of Lankswert, Patrick Sent: Thursday, January 29, 2015 4:50 AM To: 'iotivity-dev at lists.iotivity.org' Subject: Re: [dev] Control Manager Uze, If we are in agreement, how do you want to proceed regarding pulling the control-manager into master? Pat -----Original Message----- From: Lankswert, Patrick Sent: Tuesday, January 27, 2015 12:49 PM To: Macieira, Thiago Cc: iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: RE: [dev] Control Manager Thiago, I see your point. Pat -----Original Message----- From: Macieira, Thiago Sent: Tuesday, January 27, 2015 12:40 PM To: Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Control Manager On Tuesday 27 January 2015 15:25:16 Lankswert, Patrick wrote: > Thiago, > > I am not sure that we are disagreeing. I see only one public form, the > contributed code. > > Consider the case, that I contribute a bundle of source that may or > may not come from a code generator. If I contribute more source, does > it matter whether it came from a generator or from hand? I do not > think so, no matter where there code came from, it is my > responsibility to make the source code as a contribution suitable for > submission. If that means merging it with and preserving all of the > other contributions that were made since my last contributions, that > is what I must do. > > In the above scenario, the tool is irrelevant, yes? The difference is what you're modifying and whether you're following the spirit of the definition. For example, if I use my IDE to generate the skeleton of a new class, even though they're generated, the new files are the preferred form of modification. I won't regenerate them again. But I am allowed to use the tool again to generate more new classes. Similarly for us, we can use the tool again to generate new code, but we cannot use the tool to update the sources that were contributed before. That would be, at least, a violation of the spirit of the Open Source Definition and is probably enough to get us kicked out of Debian package repositories. So I am recommending a hardline stance on this: it's ok to generate once, but then no one uses the tool again on the same files. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=45a2495d99b98b699ad64ef72ee100a8d224783e143e44b8d543c6261db6206746f49c7f7f4ce1db1fdf754ed276bbedd8c023f270a836a153cb8b1934afabac2f6aaf3d92ded142cf878f9a26ce15a0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150130/19287131/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150130/19287131/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150130/19287131/attachment.p7s>
