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
>
>
>
next prev parent 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).