login
Login
/
Register
Search
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
July
»
3
Re: Handling of suspend/hibernation patches
view
thread
!MAILaRCHIVE_VOTE_RePLACE
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
[view in full thread]
From:
Rafael J. Wysocki <rjw@...>
To: Andrew Morton <akpm@...>
Cc: <linux-kernel@...>, <linux-acpi@...>, <stern@...>, <andi@...>, <greg@...>, <jbarnes@...>, <lenb@...>, <torvalds@...>, <linux-pm@...>, <sfr@...>, <pavel@...>, <mingo@...>
Subject:
Re: Handling of suspend/hibernation patches
Date: Thursday, July 3, 2008 - 5:18 pm
On Thursday, 3 of July 2008, Andrew Morton wrote:
quoted text
> On Thu, 3 Jul 2008 22:47:32 +0200 > "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > > > Hi, > > > > Recently, we've had some problems with the handling of suspend/hibernation > > patches, because they tend to touch multiple subsystems at a time. As a > > result, it usually is not clear which tree they should be included in and at > > the moment there are suspend/hibernation patches in the PCI, ACPI, x86 > > trees, as well as in -mm. Of course the resulting dependencies between those > > trees are a pain to Stephen and their maintainers. > > > > After the last Kernel Summit we tried to create a branch in the ACPI tree for > > suspend/hibernation patches (thanks Len!) and that had worked quite well until > > we started to work on the core device power management. This coincided with > > the creation of linux-next and collecting suspend/hibernation patches in the > > ACPI tree became inconvenient. > > > > Now, we could go back to the old way of handling suspend/hibernation patches, > > which was to merge them through -mm, but the disadvantage of this would be that > > the patches wouldn't go through linux-next. However, I'd like > > suspend/hibernation patches to be included in linux-next, so that they can get > > as much testing as possible. > > I need to get butt into gear and get most-of-mm into linux-next. I'll > be picking that up when 2.6.27-rc1 is done. > > So we can just keep this tree in -mm (and hence linux-next) if you like.
Well, that will save me quite a bit patch management work. :-) Let's keep that in -mm, then. Thanks, Rafael --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
Messages in current thread:
Handling of suspend/hibernation patches
, Rafael J. Wysocki
, (Thu Jul 3, 4:47 pm)
Re: Handling of suspend/hibernation patches
, Andrew Morton
, (Thu Jul 3, 5:01 pm)
Re: Handling of suspend/hibernation patches
, Rafael J. Wysocki
, (Thu Jul 3, 5:18 pm)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Jeremy Fitzhardinge
Re: [RFC 00/15] x86_64: Optimize percpu accesses
Vladislav Bolkhovitin
Re: Integration of SCST in the mainstream Linux kernel
Mike Galbraith
Re: regression: CD burning (k3b) went broke
git
:
linux-netdev
:
Jarek Poplawski
[PATCH] pkt_sched: Destroy gen estimators under rtnl_lock().
Gerrit Renker
[PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side)
Linus Torvalds
Re: [GIT]: Networking
Michael Grollman
Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945...
openbsd-misc
:
Colocation donated by:
Who's online
There are currently
1 user
and
687 guests
online.
Online users
prepackeron
Syndicate