linux-kernel - Re: Temporary ACPI maintainer for this summer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080630165037.GA30779@khazad-dum.debian.net>
Date:	Mon, 30 Jun 2008 13:50:37 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	lenb@...nel.org, torvalds@...l.org, akpm@...l.org,
	acpi@...ux.intel.com
Subject: Re: Temporary ACPI maintainer for this summer

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/