Temporary ACPI maintainer for this summer

Temporary ACPI maintainer for this summer

[Andi Kleen]

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

Re: Temporary ACPI maintainer for this summer

[Henrique de Moraes Holschuh]

On Mon, 30 Jun 2008, Andi Kleen wrote:
> 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.

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
anything else in the kernel).

> 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.

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

Re: Temporary ACPI maintainer for this summer

[Andi Kleen]

> 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.

I don't plan to use topic branches, but have a quilt/guilt workflow
that makes it possible to drop patches.

> 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?)

I prefer cleaned-up resubmission in general over incremental changes.
I would just merge the incrementals into the original patches anyways,
so the submitter does that it is best.


> 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
> anything else in the kernel).

Ok. We'll need to talk about that in detail.

>> 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.
> 
> 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?

Earlier. The tree would be based on linux-next.

-Andi