Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
Hi Denis, I have a question about the license for QSerialDevice. In gitorious it appears as GPLv3. I think it could be interesting to have a more permisive licensing option such as LGPL or BSD. This will allow to push forward this library compared with others such as QextSerialPort with not established license. Others guys and me (users of QextSerialPort) are seeking for an appropiate library for collaborating. Best regards, Àngel El 11/02/12 18:28, Denis Shienkov escribió: Hi all. I prepared for the first QtSerialPort review. But then I do not know what to do: Who will review my changes? Who will do the audit? Someone, please check the code, because I still have not figured much in the features by: http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt Best regards, Denis 09.02.2012, 23:46, marius.storm-ol...@nokia.com: On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ruwrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a script which automatically pushes the latest changes to the Gitorious location. And we prefer most people to use those as the primary clone location, since it offloads much of the resource requirements from the Qt-Project infrastructure. What then will be a public repo address on Gitorious for get/clone other people a code libraries? It's up to you really. If you don't want to mirror it to Gitorious on a regular basis, you can just use the Gerrit repo as the primary
Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
Given that the QSerialDevice developers have accepted the CLA for the project effective from start of the project, the project is now open for licencing both under LGPL and commercial license; just like any other module in Qt. AFAIK, though IANAL. -- Sent from my Nokia N9 On 2/13/12 16:56 ext Angel Perles wrote: Hi Denis, I have a question about the license for QSerialDevice. In gitorious it appears as GPLv3. I think it could be interesting to have a more permisive licensing option such as LGPL or BSD. This will allow to push forward this library compared with others such as QextSerialPort with not established license. Others guys and me (users of QextSerialPort) are seeking for an appropiate library for collaborating. Best regards, Àngel El 11/02/12 18:28, Denis Shienkov escribió: Hi all. I prepared for the first QtSerialPort review. But then I do not know what to do: Who will review my changes? Who will do the audit? Someone, please check the code, because I still have not figured much in the features by: http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt Best regards, Denis 09.02.2012, 23:46, marius.storm-ol...@nokia.com: On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ruwrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a script which automatically pushes the latest changes to the Gitorious location. And we prefer most people to use those as the primary clone location, since it
Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
Hi all. Yes, most likely LGPL + commercial. So, there is no reason to worry. Best regards, Denis 14.02.2012, 04:08, marius.storm-ol...@nokia.com: Given that the QSerialDevice developers have accepted the CLA for the project effective from start of the project, the project is now open for licencing both under LGPL and commercial license; just like any other module in Qt. AFAIK, though IANAL. -- Sent from my Nokia N9 On 2/13/12 16:56 ext Angel Perles wrote: Hi Denis, I have a question about the license for QSerialDevice. In gitorious it appears as GPLv3. I think it could be interesting to have a more permisive licensing option such as LGPL or BSD. This will allow to push forward this library compared with others such as QextSerialPort with not established license. Others guys and me (users of QextSerialPort) are seeking for an appropiate library for collaborating. Best regards, Àngel El 11/02/12 18:28, Denis Shienkov escribió: Hi all. I prepared for the first QtSerialPort review. But then I do not know what to do: Who will review my changes? Who will do the audit? Someone, please check the code, because I still have not figured much in the features by: http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt Best regards, Denis 09.02.2012, 23:46, marius.storm-ol...@nokia.com: On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ru wrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a
Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
Hi all. Well, what with the Code Review? Who controls it? I prepared the first review here: http://codereview.qt-project.org/16042 1) Interested in the question about the type of macro QT_BEGIN_NAMESPACE_XXX, QT_END_NAMESPACE_XXX, etc. What a way to more correct: leave these macros (as in the examples of projects from the playground Gerrit), or replace them with standard type QT_BEGIN_NAMESPACE, etc. (for example, the module QtSensors, etc.)? 2) Used somewhere in the build scripts, etc. variables and PUBLIC_HEADERS PRIVATE_HEADERS in *. pro files of certain modules? That is, These names are reserved specifically for the generation and integration of modules, or just this names and they are not used anywhere else except *.pro: .. HEADERS += $$PUBLIC_HEADERS $$PRIVATE_HEADERS .. ?? Best regards, Denis 11.02.2012, 21:28, Denis Shienkov scap...@yandex.ru: Hi all. I prepared for the first QtSerialPort review. But then I do not know what to do: Who will review my changes? Who will do the audit? Someone, please check the code, because I still have not figured much in the features by: http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt Best regards, Denis 09.02.2012, 23:46, marius.storm-ol...@nokia.com: On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ru wrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a script which automatically pushes the latest changes to the Gitorious
Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ru wrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a script which automatically pushes the latest changes to the Gitorious location. And we prefer most people to use those as the primary clone location, since it offloads much of the resource requirements from the Qt-Project infrastructure. What then will be a public repo address on Gitorious for get/clone other people a code libraries? It's up to you really. If you don't want to mirror it to Gitorious on a regular basis, you can just use the Gerrit repo as the primary location, though I think people will need a Jira/Gerrit account to do so? Sergio, can you please confirm or deny that? My recommendation: Keep your Gitorious repo as the primary source, and push the 2.0 branch from Gerrit to Gitorious whenever you feel it's stable enough. Then add a notice on the Gitorious project that all development is done at codereview.qt-project.org, and that Merge Requests in Gitorious is therefore disabled. For Qt Essentials, the init-repository script in qt5.git makes the Gitorious repos the 'origin', while Gerrit is the 'gerrit' remotes. -- .marius 08.02.2012, 21:37, marius.storm-ol...@nokia.com: You may now disable/stop using the Gitorious repo, and clone from Gerrit, and start pushing to refs/for/2.0 to the Gerrit repo. Then those will show up as review tasks for the 2.0 branch in Gerrit, and you can review it there. Basically, you may now use the Gerrit version as the
