[openstack-dev] Process for proposing patches attached to launchpad bugs?

Chet Burgess cfb at metacloud.com
Mon Dec 23 04:35:09 UTC 2013




On Dec 22, 2013, at 3:13 , Robert Collins <robertc at robertcollins.net> wrote:

> On 22 December 2013 18:02, Chet Burgess <cfb at metacloud.com> wrote:
>> 
>> 
>> On Dec 20, 2013, at 14:07 , Russell Bryant <rbryant at 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: cfb at metacloud.com | Tel: 855-638-2256, Ext. 2428
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131222/301b669b/attachment.html>


More information about the OpenStack-dev mailing list