Subject: Re: [PATCH] remote-bzr: reuse bzrlib transports when possible

From: Richard Hansen <[email-masked]>
Date: Sun, 08 Sep 2013 01:30:14 -0400

On 2013-09-07 20:30, Felipe Contreras wrote:
> On Sat, Sep 7, 2013 at 7:02 PM, Richard Hansen <[email-masked]> wrote:
>> On 2013-09-07 19:58, Richard Hansen wrote:
>>> Pass a list of open bzrlib.transport.Transport objects to each bzrlib
>>> function that might create a transport.  This enables bzrlib to reuse
>>> existing transports when possible, avoiding multiple concurrent
>>> connections to the same remote server.
>>>
>>> If the remote server is accessed via ssh, this fixes a couple of
>>> problems:
>>>   * If the user does not have keys loaded into an ssh agent, the user
>>>     may be prompted for a password multiple times.
>>>   * If the user is using OpenSSH and the ControlMaster setting is set
>>>     to auto, git-remote-bzr might hang.  This is because bzrlib closes
>>>     the multiple ssh sessions in an undefined order and might try to
>>>     close the master ssh session before the other sessions.  The
>>>     master ssh process will not exit until the other sessions have
>>>     exited, causing a deadlock.  (The ssh sessions are closed in an
>>>     undefined order because bzrlib relies on the Python garbage
>>>     collector to trigger ssh session termination.)
>>
>> I forgot to mention:  I didn't add a Signed-off-by line because there is
>> no mention of a copyright license at the top of git-remote-bzr.
> 
> And why is that relevant? A signed-off-by line means you wrote the
> code and you are fine with the patch being applied, or you are
> responsible somehow.

The "Developer's Certificate of Origin 1.1" in
Documentation/SubmittingPatches refers to "the open source license
indicated in the file", but there is no such indication.

However, it looks like most of the files in the repository don't
indicate which license applies.  So I guess the license in the COPYING
file (GPLv2) applies by default?  I'll re-send with the Signed-off-by
line.

Perhaps SubmittingPatches should be updated to clarify what happens if
the file doesn't indicate which license applies to the file (see
example below).

-Richard

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 7055576..c5ff744 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -227,13 +227,15 @@ the patch, which certifies that you wrote it or otherwise have
 the right to pass it on as a open-source patch.  The rules are
 pretty simple: if you can certify the below:

-        Developer's Certificate of Origin 1.1
+        Developer's Certificate of Origin 1.2

         By making a contribution to this project, I certify that:

         (a) The contribution was created in whole or in part by me and I
             have the right to submit it under the open source license
-            indicated in the file; or
+            indicated in the file (or, if no license is indicated in
+            the file, the license in COPYING that accompanies the
+            file); or

         (b) The contribution is based upon previous work that, to the best
             of my knowledge, is covered under an appropriate open source
@@ -241,7 +243,8 @@ pretty simple: if you can certify the below:
             work with modifications, whether created in whole or in part
             by me, under the same open source license (unless I am
             permitted to submit under a different license), as indicated
-            in the file; or
+            in the file (or, if no license is indicated in the file,
+            the license in COPYING that accompanies the file); or

         (c) The contribution was provided directly to me by some other
             person who certified (a), (b) or (c) and I have not modified