qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: "Justin M. Forbes" <jmforbes@linuxtx.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH master+0.14 0/2] blockdev memory leaks
Date: Wed, 09 Feb 2011 08:27:18 -0600	[thread overview]
Message-ID: <4D52A446.3040202@codemonkey.ws> (raw)
In-Reply-To: <1297260587.5185.8.camel@paddy.linuxtx.org>

On 02/09/2011 08:09 AM, Justin M. Forbes wrote:
> On Wed, 2011-02-09 at 14:52 +0100, Kevin Wolf wrote:
>    
>> Hi Justin,
>>
>> Am 08.02.2011 15:12, schrieb Markus Armbruster:
>>      
>>> Markus Armbruster (2):
>>>    blockdev: Plug memory leak in drive_uninit()
>>>    blockdev: Plug memory leak in drive_init() error paths
>>>
>>>   blockdev.c |   12 ++++++++++--
>>>   1 files changed, 10 insertions(+), 2 deletions(-)
>>>        
>> How this series made its way into stable was a bit surprising for me.
>> You may not be aware yet of the expectations that I (and probably
>> others) have in the process of patches being applied to stable. No harm
>> done, but maybe something to consider for future patches, so let me just
>> mention some points:
>>
>> I saw that you already merged these patches into the stable tree, even
>> though they are not master yet. I think usually stable should only get
>> cherry-picks from master. There are exceptions of course (e.g. when
>> something will be fixed differently in master), but I don't think this
>> is one of them.
>>
>> Also I noticed that you didn't add your Signed-off-by when applying the
>> patches. As I understand it, you should do this for any patch that you
>> apply directly (i.e. that you don't get via a git pull)
>>
>> I only caught this by chance. If you sent an email ("Thanks, applied to
>> ...") after you have applied a patch or pulled from somewhere, it would
>> be more obvious to the rest of us what happens in stable.
>>      
> Indeed, that was my fault...

No worries, it happens.

Regards,

Anthony Liguori

>   I had applied them for testing, and pushed
> to the wrong tree.  I have made some local changes to insure that this
> does not happen in the future.  The process is, pathches should be in
> master first, or their be a very good reason that they are not (bugs no
> longer apply to master, or different and more invasive fix is used in
> master).  At this point in the cycle, where there is so little
> divergence from master, there is no reason that anything in stable is
> not in master.
>
> Justin
>
>
>    

  reply	other threads:[~2011-02-09 14:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-08 14:12 [Qemu-devel] [PATCH master+0.14 0/2] blockdev memory leaks Markus Armbruster
2011-02-08 14:12 ` [Qemu-devel] [PATCH master+0.14 1/2] blockdev: Plug memory leak in drive_uninit() Markus Armbruster
2011-02-08 14:12 ` [Qemu-devel] [PATCH master+0.14 2/2] blockdev: Plug memory leak in drive_init() error paths Markus Armbruster
2011-02-09 12:10 ` [Qemu-devel] Re: [PATCH master+0.14 0/2] blockdev memory leaks Kevin Wolf
2011-02-09 13:52 ` Kevin Wolf
2011-02-09 14:09   ` Justin M. Forbes
2011-02-09 14:27     ` Anthony Liguori [this message]
2011-02-09 14:37     ` Kevin Wolf

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=4D52A446.3040202@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=Qemu-devel@nongnu.org \
    --cc=armbru@redhat.com \
    --cc=jmforbes@linuxtx.org \
    --cc=kwolf@redhat.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).