qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Cc: qemu-devel@nongnu.org, John Snow <jsnow@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: Re: [RFC qemu 0/6] mirror: implement incremental and bitmap modes
Date: Thu, 3 Sep 2020 15:43:08 +0200	[thread overview]
Message-ID: <20200903134308.GE8835@linux.fritz.box> (raw)
In-Reply-To: <1599140071.n44h532eeu.astroid@nora.none>

Am 03.09.2020 um 15:36 hat Fabian Grünbichler geschrieben:
> On September 3, 2020 3:23 pm, Kevin Wolf wrote:
> > Am 03.09.2020 um 14:57 hat Max Reitz geschrieben:
> >> On 03.09.20 14:38, Kevin Wolf wrote:
> >> > Am 03.09.2020 um 13:04 hat Max Reitz geschrieben:
> >> >> On 03.09.20 12:13, Fabian Grünbichler wrote:
> >> >>> On August 21, 2020 3:03 pm, Max Reitz wrote:
> >> >>>> On 18.02.20 11:07, Fabian Grünbichler wrote:
> >> >>> I am not sure how 
> >> >>> the S-O-B by John is supposed to enter the mix - should I just include 
> >> >>> it in the squashed patch (which would be partly authored, but 
> >> >>> not-yet-signed-off by him otherwise?)?
> >> >>
> >> >> I’m not too sure on the proceedings, actually.  I think it should be
> >> >> fine if you put his S-o-b there, as long as your patch is somehow based
> >> >> on a patch that he sent earlier with his S-o-b underneath.  But I’m not
> >> >> sure.
> >> > 
> >> > Signed-off-by means that John certifies the DCO for the patch (at least
> >> > the original version that you possibly modified), so you cannot just add
> >> > it without asking him.
> >> 
> >> But what if you take a patch from someone and heavily modify it –
> >> wouldn’t you keep the original S-o-b and explain the modifications in
> >> the commit message?
> > 
> > Ah, if that patch already had a S-o-b, then yes. You keep it not only to
> > show who touched the patch, but also because your own S-o-b depends on
> > the one from the original author (you only have the rights to contribute
> > it because the original author had them and could pass them on to you).
> > 
> > I thought it was based on a patch that came without S-o-b.
> 
> it is (taken from John's git, with his approval, and implicit admission 
> that S-O-B is just missing because it was a WIP branch/tree that I 
> started from). that was also the reason why I kept that patch unmodified 
> and sent my modifications as patches on-top, to make it easier for John 
> to verify that that one patch is his original WIP one and add this 
> missing S-O-B ;)

Yeah, then John should just reply to the patch and add the S-o-b.

Complications like this are why I always use 'git commit -s' and have it
already in my development branches rather than only adding it when
preparing the patch emails to send.

Kevin



  reply	other threads:[~2020-09-03 13:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-18 10:07 [RFC qemu 0/6] mirror: implement incremental and bitmap modes Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 1/6] drive-mirror: add support for sync=bitmap mode=never Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 2/6] drive-mirror: add support for conditional and always bitmap sync modes Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 3/6] mirror: add check for bitmap-mode without bitmap Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 4/6] mirror: switch to bdrv_dirty_bitmap_merge_internal Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 5/6] iotests: add test for bitmap mirror Fabian Grünbichler
2020-02-18 10:07 ` [RFC qemu 6/6] mirror: move some checks to QMP Fabian Grünbichler
2020-02-18 10:43 ` [RFC qemu 0/6] mirror: implement incremental and bitmap modes no-reply
2020-02-25 21:54 ` John Snow
2020-04-03 11:34   ` Fabian Grünbichler
2020-08-21 13:03 ` Max Reitz
2020-08-24 15:54   ` John Snow
2020-09-03 10:13   ` Fabian Grünbichler
2020-09-03 11:04     ` Max Reitz
2020-09-03 12:38       ` Kevin Wolf
2020-09-03 12:57         ` Max Reitz
2020-09-03 13:23           ` Kevin Wolf
2020-09-03 13:36             ` Fabian Grünbichler
2020-09-03 13:43               ` Kevin Wolf [this message]
2020-09-03 13:51               ` Max Reitz

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=20200903134308.GE8835@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).