Re: [openstack-dev] Process for proposing patches attached to launchpad bugs?
On Mon, Dec 23, 2013 at 3:50 AM, Robert Collins robe...@robertcollins.netwrote: On 23 December 2013 17:35, Chet Burgess c...@metacloud.com wrote: It's unclear to me what exactly constitutes writing a new patch. I can check out oslo.messaging, and without trying to merge the patch just go and make the same change (its literarily a 2 line change). I can write the tests, and I can submit it (which I'm happy to do, I really want this bug fixed). Honestly though this change is so trivial I don't see how my patch would look all that different from the one already posted. I know there is prior art. The mixin class that kombu provides does the exact same thing. Is that Research the term 'de minimis' WRT copyright and decide (with the help of actual legal advice if necessary) when to just go ahead and submit a patch. Prior art is a patent concept, not related to copyright. Copyright is +1...this stuff gets confused too much these days... dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Process for proposing patches attached to launchpad bugs?
On 22 December 2013 18:02, Chet Burgess c...@metacloud.com wrote: On Dec 20, 2013, at 14:07 , Russell Bryant rbry...@redhat.com wrote: It's not your code, so you really can't propose it without them having signed the CLA, or propose it as your own. Is there a time limit on this sort of thing? As an example there is a bug we opened 2 years ago that still has not been fixed. Someone posted a patch to the laundpad 4 months ago that addresses the issue but hasn't submitted a review. How long do we wait before its ok to submit the patch so we can have the fix? Is there some way we can note where the original code came from so as not to be viewed as stealing credit? I ask now because I planned on posted a review with tests in next week or so because we really need the fix (https://bugs.launchpad.net/nova/+bug/856764). There is a time limit - 70 years after the authors death. I suggest not waiting for that and instead writing a new patch yourself. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Process for proposing patches attached to launchpad bugs?
On Dec 22, 2013, at 3:13 , Robert Collins robe...@robertcollins.net wrote: On 22 December 2013 18:02, Chet Burgess c...@metacloud.com wrote: On Dec 20, 2013, at 14:07 , Russell Bryant rbry...@redhat.com wrote: It's not your code, so you really can't propose it without them having signed the CLA, or propose it as your own. Is there a time limit on this sort of thing? As an example there is a bug we opened 2 years ago that still has not been fixed. Someone posted a patch to the laundpad 4 months ago that addresses the issue but hasn't submitted a review. How long do we wait before its ok to submit the patch so we can have the fix? Is there some way we can note where the original code came from so as not to be viewed as stealing credit? I ask now because I planned on posted a review with tests in next week or so because we really need the fix (https://bugs.launchpad.net/nova/+bug/856764). There is a time limit - 70 years after the authors death. I suggest not waiting for that and instead writing a new patch yourself. It's unclear to me what exactly constitutes writing a new patch. I can check out oslo.messaging, and without trying to merge the patch just go and make the same change (its literarily a 2 line change). I can write the tests, and I can submit it (which I'm happy to do, I really want this bug fixed). Honestly though this change is so trivial I don't see how my patch would look all that different from the one already posted. I know there is prior art. The mixin class that kombu provides does the exact same thing. Is that sufficient? What else would need to be done to make this free an clear for our use? I'm going to try reaching out to the author to see if I can sort it that way, but this still seems like there is a general problem here. Given the current interpretation of the IP laws someone has an effective way to block progress on a feature, blueprint, or project as a whole. Create a launchpad account, don't sign the CLA, just start posting implementations to launchpad. If the simple act of reading the bugs now encumbers us from being able to fix them in a certain way or using certain patterns we have a potentially serious issue. If this is really the case should we not lock the bug tracker to only those who have signed the CLA or have the TOU clearly state that any code posted is automatically ASLv2? Am I misunderstanding the scope of this problem? -- Chet Burgess Vice President, Engineering | Metacloud, Inc. Email: c...@metacloud.com | Tel: 855-638-2256, Ext. 2428___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Process for proposing patches attached to launchpad bugs?
On Dec 20, 2013, at 14:07 , Russell Bryant rbry...@redhat.com wrote: It's not your code, so you really can't propose it without them having signed the CLA, or propose it as your own. Is there a time limit on this sort of thing? As an example there is a bug we opened 2 years ago that still has not been fixed. Someone posted a patch to the laundpad 4 months ago that addresses the issue but hasn't submitted a review. How long do we wait before its ok to submit the patch so we can have the fix? Is there some way we can note where the original code came from so as not to be viewed as stealing credit? I ask now because I planned on posted a review with tests in next week or so because we really need the fix (https://bugs.launchpad.net/nova/+bug/856764). -- Chet Burgess___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Process for proposing patches attached to launchpad bugs?
In the past, I've been able to get authors of bug fixes attached to Launchpad bugs to sign the CLA and submit the patch through gerrit... although, in one case it took quite a bit of time (and thankfully it wasn't a critical fix or anything). This scenario just came up again (example: [1]), so I'm asking preemptively... what if the author is unwilling / unable in signing the CLA and propose through gerrit, or it's a critical bug fix and waiting on an author to go through the CLA process is undesirable for the community? Obviously that's a bit of a fail on our part, but what's the most appropriate expedient way to handle it? Can we propose the patch to gerrit ourselves? If so, who should appear as the --author of the commit? Who should appear as Co-Authored-By, especially when the committer helps to evolve the patch evolves further in review? Alternatively, am I going about this all wrong? Thanks! [1]: https://bugs.launchpad.net/keystone/+bug/1198171/comments/8 -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Process for proposing patches attached to launchpad bugs?
On 12/20/2013 09:32 AM, Dolph Mathews wrote: In the past, I've been able to get authors of bug fixes attached to Launchpad bugs to sign the CLA and submit the patch through gerrit... although, in one case it took quite a bit of time (and thankfully it wasn't a critical fix or anything). This scenario just came up again (example: [1]), so I'm asking preemptively... what if the author is unwilling / unable in signing the CLA and propose through gerrit, or it's a critical bug fix and waiting on an author to go through the CLA process is undesirable for the community? Obviously that's a bit of a fail on our part, but what's the most appropriate expedient way to handle it? Can we propose the patch to gerrit ourselves? If so, who should appear as the --author of the commit? Who should appear as Co-Authored-By, especially when the committer helps to evolve the patch evolves further in review? Alternatively, am I going about this all wrong? Thanks! [1]: https://bugs.launchpad.net/keystone/+bug/1198171/comments/8 It's not your code, so you really can't propose it without them having signed the CLA, or propose it as your own. Ideally have someone else fix the same bug that hasn't looked at the patch. From a quick look, it seems likely that this fix is small and straight forward enough that the clean new implementation is going to end up looking very similar. Still, I think it's the right thing to do. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
