From: Gleb Natapov <gleb@redhat.com>
To: Scott Wood <scottwood@freescale.com>
Cc: Alexander Graf <agraf@suse.de>,
kvm-ppc@vger.kernel.org,
"kvm@vger.kernel.org mailing list" <kvm@vger.kernel.org>,
Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PULL 0/7] ppc patch queue 2013-03-22
Date: Sun, 31 Mar 2013 10:49:35 +0000 [thread overview]
Message-ID: <20130331104935.GA21968@redhat.com> (raw)
In-Reply-To: <1364315862.469.0@snotra>
On Tue, Mar 26, 2013 at 11:37:42AM -0500, Scott Wood wrote:
> On 03/25/2013 08:33:12 PM, Gleb Natapov wrote:
> >On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
> >>
> >> On 26.03.2013, at 00:16, Scott Wood wrote:
> >>
> >> > On 03/25/2013 05:59:39 PM, Alexander Graf wrote:
> >> >> On 25.03.2013, at 23:54, Scott Wood wrote:
> >> >> > On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
> >> >> >> On 25.03.2013, at 23:21, Scott Wood wrote:
> >> >> >> > -next? These are bugfixes, at least partially for
> >regressions from 3.8 (that I pointed out before the bugs were
> >merged!), that should go into master.
> >> >> >> >
> >> >> >> > Also, what about:
> >> >> >> > http://patchwork.ozlabs.org/patch/226227/
> >> >> >> >
> >> >> >> > You've got all four patches in kvm-ppc-3.9 as of a few
> >weeks ago -- will you be requesting a pull for that soon?
> >> >> >> Sigh. I guess I've screwed up the whole "let's make -next
> >an unusable tree and fix regressions in a separate one" workflow
> >again. Sorry for that.
> >> >> >> Since the patches already trickled into kvm's next branch,
> >all we can do now is to wait for them to come back through stable,
> >right? Marcelo, Gleb?
> >> >> >
> >> >> > Well, you can still submit that kvm-ppc-3.9 pull request. :-)
> >> >> I can, but nobody would pull it, as it'd create ugly merge
> >commits when 3.10 opens
> >> >
> >> > That's a lousy excuse for leaving bugs unfixed.
> >>
> >> I agree. So if it doesn't hurt to have the same commits in
> >kvm/next and kvm/master, I'd be more than happy to send another
> >pull request with the important fixes against kvm/master as well.
> >>
> >If it will result in the same commit showing twice in the Linus
> >tree in 3.10 we cannot do that.
>
> Why?
>
Because Linus distastes it and mat refuse to pull. There is a way to avoid
such double commits: push fix to Linus tree and merge it back to next.
--
Gleb.
WARNING: multiple messages have this Message-ID (diff)
From: Gleb Natapov <gleb@redhat.com>
To: Scott Wood <scottwood@freescale.com>
Cc: Alexander Graf <agraf@suse.de>,
kvm-ppc@vger.kernel.org,
"kvm@vger.kernel.org mailing list" <kvm@vger.kernel.org>,
Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PULL 0/7] ppc patch queue 2013-03-22
Date: Sun, 31 Mar 2013 13:49:35 +0300 [thread overview]
Message-ID: <20130331104935.GA21968@redhat.com> (raw)
In-Reply-To: <1364315862.469.0@snotra>
On Tue, Mar 26, 2013 at 11:37:42AM -0500, Scott Wood wrote:
> On 03/25/2013 08:33:12 PM, Gleb Natapov wrote:
> >On Tue, Mar 26, 2013 at 12:35:09AM +0100, Alexander Graf wrote:
> >>
> >> On 26.03.2013, at 00:16, Scott Wood wrote:
> >>
> >> > On 03/25/2013 05:59:39 PM, Alexander Graf wrote:
> >> >> On 25.03.2013, at 23:54, Scott Wood wrote:
> >> >> > On 03/25/2013 05:32:11 PM, Alexander Graf wrote:
> >> >> >> On 25.03.2013, at 23:21, Scott Wood wrote:
> >> >> >> > -next? These are bugfixes, at least partially for
> >regressions from 3.8 (that I pointed out before the bugs were
> >merged!), that should go into master.
> >> >> >> >
> >> >> >> > Also, what about:
> >> >> >> > http://patchwork.ozlabs.org/patch/226227/
> >> >> >> >
> >> >> >> > You've got all four patches in kvm-ppc-3.9 as of a few
> >weeks ago -- will you be requesting a pull for that soon?
> >> >> >> Sigh. I guess I've screwed up the whole "let's make -next
> >an unusable tree and fix regressions in a separate one" workflow
> >again. Sorry for that.
> >> >> >> Since the patches already trickled into kvm's next branch,
> >all we can do now is to wait for them to come back through stable,
> >right? Marcelo, Gleb?
> >> >> >
> >> >> > Well, you can still submit that kvm-ppc-3.9 pull request. :-)
> >> >> I can, but nobody would pull it, as it'd create ugly merge
> >commits when 3.10 opens
> >> >
> >> > That's a lousy excuse for leaving bugs unfixed.
> >>
> >> I agree. So if it doesn't hurt to have the same commits in
> >kvm/next and kvm/master, I'd be more than happy to send another
> >pull request with the important fixes against kvm/master as well.
> >>
> >If it will result in the same commit showing twice in the Linus
> >tree in 3.10 we cannot do that.
>
> Why?
>
Because Linus distastes it and mat refuse to pull. There is a way to avoid
such double commits: push fix to Linus tree and merge it back to next.
--
Gleb.
next prev parent reply other threads:[~2013-03-31 10:49 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-22 14:25 [PULL 0/7] ppc patch queue 2013-03-22 Alexander Graf
2013-03-22 14:25 ` Alexander Graf
2013-03-22 14:25 ` [PATCH 1/7] KVM: PPC: move tsr update in a separate function Alexander Graf
2013-03-22 14:25 ` Alexander Graf
2013-03-22 14:25 ` [PATCH 2/7] KVM: PPC: Added one_reg interface for timer registers Alexander Graf
2013-03-22 14:25 ` Alexander Graf
2013-03-22 14:25 ` [PATCH 3/7] KVM: PPC: booke: Added debug handler Alexander Graf
2013-03-22 14:25 ` Alexander Graf
2013-03-22 14:26 ` [PATCH 4/7] kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid Alexander Graf
2013-03-22 14:26 ` Alexander Graf
2013-03-22 14:26 ` [PATCH 5/7] kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit Alexander Graf
2013-03-22 14:26 ` Alexander Graf
2013-03-22 14:26 ` [PATCH 6/7] kvm/ppc/e500: eliminate tlb_refs Alexander Graf
2013-03-22 14:26 ` Alexander Graf
2013-03-22 14:26 ` [PATCH 7/7] KVM: PPC: Remove unused argument to kvmppc_core_dequeue_external Alexander Graf
2013-03-22 14:26 ` Alexander Graf
2013-03-24 9:45 ` [PULL 0/7] ppc patch queue 2013-03-22 Gleb Natapov
2013-03-24 9:45 ` Gleb Natapov
2013-03-25 22:21 ` Scott Wood
2013-03-25 22:21 ` Scott Wood
2013-03-25 22:32 ` Alexander Graf
2013-03-25 22:32 ` Alexander Graf
2013-03-25 22:54 ` Scott Wood
2013-03-25 22:54 ` Scott Wood
2013-03-25 22:59 ` Alexander Graf
2013-03-25 22:59 ` Alexander Graf
2013-03-25 23:16 ` Scott Wood
2013-03-25 23:16 ` Scott Wood
2013-03-25 23:35 ` Alexander Graf
2013-03-25 23:35 ` Alexander Graf
2013-03-26 1:33 ` Gleb Natapov
2013-03-26 1:33 ` Gleb Natapov
2013-03-26 1:59 ` Paul Mackerras
2013-03-26 1:59 ` Paul Mackerras
2013-04-11 13:45 ` Marcelo Tosatti
2013-04-11 13:45 ` Marcelo Tosatti
2013-04-11 13:50 ` Alexander Graf
2013-04-11 13:50 ` Alexander Graf
2013-04-12 20:54 ` Marcelo Tosatti
2013-04-12 20:54 ` Marcelo Tosatti
2013-04-12 20:56 ` Alexander Graf
2013-04-12 20:56 ` Alexander Graf
2013-04-16 17:26 ` Alexander Graf
2013-04-16 17:26 ` Alexander Graf
2013-04-16 21:28 ` Marcelo Tosatti
2013-04-16 21:28 ` Marcelo Tosatti
2013-03-26 16:37 ` Scott Wood
2013-03-26 16:37 ` Scott Wood
2013-03-31 10:49 ` Gleb Natapov [this message]
2013-03-31 10:49 ` Gleb Natapov
2013-03-31 11:05 ` Alexander Graf
2013-03-31 11:05 ` Alexander Graf
2013-04-08 18:17 ` Scott Wood
2013-04-08 18:17 ` Scott Wood
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=20130331104935.GA21968@redhat.com \
--to=gleb@redhat.com \
--cc=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=scottwood@freescale.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.