From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: Temporary ACPI maintainer for this summer Date: Mon, 30 Jun 2008 19:23:53 +0200 Message-ID: <486916A9.8050808@firstfloor.org> References: <871w2fujga.fsf@basil.nowhere.org> <20080630165037.GA30779@khazad-dum.debian.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from one.firstfloor.org ([213.235.205.2]:53637 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755382AbYF3RX5 (ORCPT ); Mon, 30 Jun 2008 13:23:57 -0400 In-Reply-To: <20080630165037.GA30779@khazad-dum.debian.net> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Henrique de Moraes Holschuh Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, lenb@kernel.org, torvalds@osdl.org, akpm@osdl.org, acpi@linux.intel.com > 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