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] [day] [month] [year] [list]

Date:	Mon, 30 Jun 2008 19:23:53 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
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


> 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

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