From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
Daniel De Graaf <dgdegra@tycho.nsa.gov>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: Re: 2.6.39 merge window (git pulls and what is planned to go in)
Date: Tue, 15 Mar 2011 19:52:49 +0000 [thread overview]
Message-ID: <1300218769.15812.8.camel@localhost.localdomain> (raw)
In-Reply-To: <AANLkTi=sEJexxiapPbkW7j4a08xkyx=iwRVdbxgGpZkQ@mail.gmail.com>
On Tue, 2011-03-15 at 16:53 +0000, Shriram Rajagopalan wrote:
> On Tue, Mar 15, 2011 at 8:12 AM, Ian Campbell
> <Ian.Campbell@eu.citrix.com> wrote:
> > On Fri, 2011-03-11 at 14:21 +0000, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Mar 11, 2011 at 09:11:31AM +0000, Ian Campbell wrote:
> >> > On Thu, 2011-03-10 at 19:29 +0000, Konrad Rzeszutek Wilk wrote:
> >> > > Probably over the weekend Linus is going to open the merge window.
> >> > >
> >> > > This merge window is much more complicated than the previous
> >> > > one b/c we got a lot of good stuff.
> >> > >
> >> > > For my sanity and book-keeping I was thinking to email Linus
> >> > > five git pull requests:
> >> > [...]
> >> > > .. and then during the next week of the two weeks merge window:
> >> > [...]
> >> > > In this order or so.
> >> >
> >> > Seems sane. I'm going to rebase my dev tree onto all these now (I think
> >> > I've got most of it already)
> >>
> >> OK. #linux-next is you place then.
> >> >
> >> > > In other trees by other maintainers we have:
> >> > [...]
> >> > > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git has
> >> > > xen suspend cleanups
> >> > > PVonHVM improvements - makes spinlocks be PV aware, balloon in HVM
> >> >
> >> > Are Shriram's suspend/checkpoint patches in the pipeline somewhere?
> >>
> >> <head smack> I knew I forgot something.
> >>
> >> The last I heard he was battling PVonHVM shutdown issues during his
> >> testing of his patches.
> >>
> >> Shririam?
> >
> > He posted a series on Saturday, rebased onto Stefano's PVHVM tree + the
> > PM tree, it looked sane to me.
> >
> > I think his patch 1/5 (the one from Kazuhiro Suzuki) could go in any
> > time since it has no dependency on either the PVHVM or PM trees.
> >
> > It also looks to me like patch 4/5 ("PM: Add visible
> > HIBERNATION_INTERFACE and hide HIBERNATION") could go upstream via the
> > PM tree whenever Rafael likes, since it doesn't depend on any of the
> > others. That just leaves 2/5, 3/5 and 5/5 to be pushed through once
>
> I wish it was that easy. Rafael's tree carries a commit that is
> missing from both
> Konrad's and Stefano's tree.
>
> "PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME)"
>
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -38,7 +38,7 @@ config XEN_MAX_DOMAIN_MEMORY
>
> config XEN_SAVE_RESTORE
> bool
> - depends on XEN && PM
> + depends on XEN
> default y
>
> config XEN_DEBUG_FS
>
> 5/5 is based on this patch and that is the reason I had to create a
> hybrid tree and base my patches on it. If this conflict can be easily resolved by whoever
> is doing the merging, then I can resend the 5/5 alone based on stefano's tree and
> Ian's idea of pushing 2,3,5/5 through xen tree would work.
4/5 needs to be upstream (via Rafael) first though, doesn't it? That's
the keystone here, the rest appears to fall out nicely once that has
gone in.
Certainly the conflict above isn't (IMHO) worth worrying about in and of
itself, it will be trivially resolved when Linus does the pull. (doubly
so if the pull request warns him it's coming and says what to do...)
> > everything else has settled down.
> >
> This "everything else has settled down" phrase has been causing lot of
> delays :P.
It's unfortunately often the case when a change spans multiple
maintainers.
Ian.
next prev parent reply other threads:[~2011-03-15 19:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 19:29 2.6.39 merge window (git pulls and what is planned to go in) Konrad Rzeszutek Wilk
2011-03-11 1:26 ` Jeremy Fitzhardinge
2011-03-11 9:11 ` Ian Campbell
2011-03-11 14:21 ` Konrad Rzeszutek Wilk
2011-03-15 15:12 ` Ian Campbell
2011-03-15 16:53 ` Shriram Rajagopalan
2011-03-15 19:52 ` Ian Campbell [this message]
2011-03-15 20:12 ` Shriram Rajagopalan
2011-03-15 20:58 ` Ian Campbell
2011-03-15 22:16 ` Konrad Rzeszutek Wilk
2011-03-16 9:40 ` Ian Campbell
2011-03-16 14:29 ` Konrad Rzeszutek Wilk
2011-03-16 14:38 ` Ian Campbell
2011-03-16 15:28 ` Shriram Rajagopalan
2011-03-16 15:58 ` Konrad Rzeszutek Wilk
2011-03-16 16:08 ` Ian Campbell
2011-03-16 16:21 ` Konrad Rzeszutek Wilk
2011-03-16 16:24 ` Ian Campbell
2011-03-16 17:12 ` Shriram Rajagopalan
2011-03-18 13:59 ` Re: 2.6.39 merge window - git pulls and what went in Konrad Rzeszutek Wilk
2011-03-18 14:36 ` Stephan Seitz
2011-03-18 14:39 ` Stefano Stabellini
2011-03-16 15:23 ` Re: 2.6.39 merge window (git pulls and what is planned to go in) Shriram Rajagopalan
2011-03-16 16:15 ` Ian Campbell
2011-03-11 11:00 ` Stefano Stabellini
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=1300218769.15812.8.camel@localhost.localdomain \
--to=ian.campbell@eu.citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=rshriram@cs.ubc.ca \
--cc=xen-devel@lists.xensource.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.