On Fri, 15 Dec 2006 01:01:40 -0500 Len Brown <lenb@xxxxxxxxxx> wrote: > > When will it be sent to Linus? > > > > I cannot feasibly carry this work, the outstanding x86_64 work, the > > outstanding i386 work and the outstanding ACPI work in -mm. > > > > As the acpi patch is the one which has disrupted the other trees I dropped > > that, so what little bit of testing gets donw in -mm won't be available. > > Until the ACPICA update can survive for a few rounds of -mm > with no regressions reported, I'm not going to send it to Linus. > > So removing it from -mm in favor of Andi's patches that may > be up-stream bound shortly was the right decision. I doubt if Andi is planning on getting much of this work into 2.6.20. > > > Nearly all of this series has been in -mm before. > > > > > > I do regret that there are more variable re-names and whitespace > > > cleanups in this batch than I'd prefer -- seems there is never > > > a good time to do those... > > > > There are ways of doing these things which don't cause such breakage. > > Whitespace cleanups go to the subsystem maintainer and NOT in the ACPI > > tree. For renames, you can add back-compat defines in the acpi headers, > > send that and the rename patch to the subsytem maintainer and when it's all > > merged up, remove the back-compat stuff. > > Agreed. > Perhaps in January some re-write can be done to make the series smaller. > > For now I will remove the ACPICA update from my test branch > so that it doesn't block the unrelated patches that should go up now. > The ACPICA update will still be available on a dedicated acpica branch. OK, thanks. I'll resync with gti-acpi and will go through another round of squirting patches at everyone. But the problem remains: there is outstanding work in ACPICA which conflicts with outstanding x86/x86_64 work. Once those two patchsets finally coincide somewhere, things will blow up. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
