Len Brown is on sabbatical from Intel this summer. While he's away

I'm serving as the temporary ACPI maintainer. Please send all ACPI

mails and patches you would normally send to Len to me, ideally cc

linux-acpi@vger.kernel.org.
As usual please put all ACPI bug reports into http://bugzilla.kernel.org.
First (in case he still reads that) I would like to thank Len (and all

the other ACPI hackers of course) for all the great work done on the ACPI

code in the last years, turning it from a problem child to a quite

respectable kernel subsystem.
I'm not as deep in all things ACPI as Len is, so I'll often rely on

the various other ACPI hackers for specific issues.
My main goal will be to merge patches from the usual contributors and

try to keep the ACPI bugs and regressions under control. I don't plan

many new features, but features already in progress will be processed

as they are ready.
I'm also not full time working on ACPI, but also active in other areas.

This means I will not write that many ACPI patches myself

or do extensive testing on my own, but mostly focus on review and merging

and bug triage.
The git tree setup for the merges will be announced later.  I won't

directly use Len's tree.
I'll take over all patches Len has already queued, so no need to

resubmit them.  But if he doesn't have something acknowledged already

you want to be included, please retransmit it to me.
The .27 merge will be primarily patches Len has already queued

in his release tree.
-Andi

--

Andi,
Len usually stores all changes from different sub-maintainers in separate

topic branches, and as long as the tree had not been sent to Linus for

mainline merge yet, he would even let us resubmit patchsets (instead of

asking for incremental fixes):  he'd just drop the old topic branch with

that patchset, and create it anew using the new patchset.
Not every sub-maintainer took advantage of this, but some of us did.  It

would be nice to know beforehand how you're going to handle these issues

(i.e. do you prefer incremental fixing on stuff already staged for

submission, or a cleaned-up resubmission for re-staging?)
Also, as you should know, Len is the upstream path for some "platform

drivers" that are big ACPI users but not ACPI drivers in itself (mostly

laptop firmware drivers that live in drivers/misc).
These drivers have ties to subsystems spread all over the kernel (major ACPI

ties, but also leds, input, rfkill, gpio, hwmon...), so they often get

patches that require late merging (end of the merge window, early -rc1)

because of dependencies to subsystems outside ACPI.  Len was fine with it,

as long as the changes were local to the drivers (very low breakage risk for
You will get a bunch of thinkpad-acpi patches that depend upon net-next-2.6

soon...  I was waiting for some rfkill improvements to land on net-next-2.6

before submitting code that needs them.
That's something else I'd like to know.  Do you prefer to get such changes

[that depend on stuff still being submitted to other subsystems] early, or

only after their dependencies are already on a (mostly) assured path to

mainline?
--

  "One disk to rule them all, One disk to find them. One disk to bring

  them all and in the darkness grind them. In the Land of Redmond

  where the shadows lie." -- The Silicon Valley Tarot

  Henrique Holschuh

--

I don't plan to use topic branches, but have a quilt/guilt workflow
I prefer cleaned-up resubmission in general over incremental changes.

I would just merge the incrementals into the original patches anyways,
Earlier. The tree would be based on linux-next.
-Andi
--