git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Hansen <rhansen@bbn.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] remote-bzr: reuse bzrlib transports when possible
Date: Sun, 08 Sep 2013 01:30:14 -0400	[thread overview]
Message-ID: <522C0B66.1080707@bbn.com> (raw)
In-Reply-To: <CAMP44s0uHs8=r1eh2D-jdj563co5y7Rr1_6u=xoZDC52A6CPTQ@mail.gmail.com>

On 2013-09-07 20:30, Felipe Contreras wrote:
> 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

  reply	other threads:[~2013-09-08  5:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-07 23:58 [PATCH] remote-bzr: reuse bzrlib transports when possible Richard Hansen
2013-09-08  0:02 ` Richard Hansen
2013-09-08  0:30   ` Felipe Contreras
2013-09-08  5:30     ` Richard Hansen [this message]
2013-09-08  5:47       ` [PATCH v2] " Richard Hansen
2013-09-09 17:55         ` Junio C Hamano
2013-09-10 22:01           ` Junio C Hamano
2013-09-12 21:05             ` Richard Hansen
2013-09-12 21:11               ` Junio C Hamano
2013-09-08  0:27 ` [PATCH] " Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=522C0B66.1080707@bbn.com \
    --to=rhansen@bbn.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).