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 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- [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 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 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 https://lists.iotivity.org/mailman/listinfo/iotivity-dev
