All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-stable <qemu-stable@nongnu.org>,
	Thomas Huth <thuth@redhat.com>, Bin Meng <bmeng@tinylab.org>,
	Paul Menzel <pmenzel@molgen.mpg.de>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>
Subject: Re: cherry-picking something to -stable which might require other changes
Date: Tue, 12 Sep 2023 16:23:28 +0100	[thread overview]
Message-ID: <ZQCCcM1gUy3ODnyj@redhat.com> (raw)
In-Reply-To: <CAJSP0QUfF64wWQbbAqKpeUWGEOz6jB2ZHkmJhaRXfRDFLpD_kw@mail.gmail.com>

On Tue, Sep 12, 2023 at 10:00:46AM -0400, Stefan Hajnoczi wrote:
> When I backport patches into RHEL, the general process I follow is:
> 1. For context conflicts, just adjust the patch to resolve them.
> 2. For real dependencies, backport the dependencies, if possible.
> 3. If backporting the dependencies is not possible, think of a
> downstream-only solution. This should be rare.
> 
> People make different backporting decisions (just like structuring
> patch series). It can be a matter of taste.

I tend to try to cherry-pick the dependancies in case (1) too
unless they are functionally invasive. Any time you manually
adjust a patch, you increase the likelihood that later cherry
picks will also require manual work. So I always favour a clean
cherry-pick until the point the functional risk becomes
unacceptable in the context of testing the change I'm pulling
back.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  parent reply	other threads:[~2023-09-12 15:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12 13:44 cherry-picking something to -stable which might require other changes Michael Tokarev
2023-09-12 14:00 ` Stefan Hajnoczi
2023-09-12 14:41   ` Warner Losh
2023-09-12 15:23   ` Daniel P. Berrangé [this message]
2023-09-12 18:01     ` Michael Tokarev
2023-09-12 18:11       ` Daniel P. Berrangé

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=ZQCCcM1gUy3ODnyj@redhat.com \
    --to=berrange@redhat.com \
    --cc=bmeng@tinylab.org \
    --cc=mjt@tls.msk.ru \
    --cc=pbonzini@redhat.com \
    --cc=pmenzel@molgen.mpg.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.com \
    --cc=thuth@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.