git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
RHRichard Hansen <rhansen@bbn.com>
Date
Sep 8, 2013, 05:30 UTC
Message-ID
<522C0B66.1080707@bbn.com>
In-Reply-To
<CAMP44s0uHs8=r1eh2D-jdj563co5y7Rr1_6u=xoZDC52A6CPTQ@mail.gmail.com>
On 2013-09-07 20:30, Felipe Contreras wrote:
Show 26 quoted lines
> On Sat, Sep 7, 2013 at 7:02 PM, Richard Hansen <rhansen@bbn.com> 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
Previous: Felipe ContrerasNext: Richard Hansen
Message 4 of 10 in “remote-bzr: reuse bzrlib transports when possible”
  1. remote-bzr: reuse bzrlib transports when possibleRichard Hansen, Sep 7, 2013
  2. Richard HansenSep 8, 2013
  3. Felipe ContrerasSep 8, 2013
  4. Richard HansenSep 8, 2013
  5. remote-bzr: reuse bzrlib transports when possibleRichard Hansen, Sep 8, 2013
  6. Junio C HamanoSep 9, 2013
  7. Junio C HamanoSep 10, 2013
  8. Richard HansenSep 12, 2013
  9. Junio C HamanoSep 12, 2013
  10. Felipe ContrerasSep 8, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.