Re: Temporary ACPI maintainer for this summer

[Andi Kleen <andi@firstfloor.org>]

> 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