On Thu, 2008-04-10 at 13:23 -0400, Len Brown wrote: > On Thursday 10 April 2008, Henrique de Moraes Holschuh wrote: > > On Thu, 10 Apr 2008, Len Brown wrote: > > > hmmm, if we drop this series as-is into acpi-test then it will fail due to no "brightness_get"... > > > > Yeah. How do you want to handle this? Defer the drop into acpi-test > > until Richard's tree gets merged, or maybe *temporarily* merge his tree > > in acpi-test along with thinkpad-acpi stuff? > > > > I can prepare a changeset with the patches needed from Richard's tree, > > if you prefer that to a git pull and would prefer to have those patches > > around acpi-test so that thinkpad-acpi can be merged sooner. > > > > I wanted to send you my queue before the merge window opens, so that > > people could look at the patches, etc. That's why I sent them in before > > Richard's tree got merged. The thinkpad-acpi patches did get some > > testing already, in the thinkpad-acpi sourceforge releases. > > Richard, > > If the patches that Henrique depends on are unlikely to change, > then I'll be happy to put them on a branch in my tree and put > henrique's driver on top of them. If they go upstream via your > tree and/or mine and are identical, then that works fine. > > However, if i check them into my tree and then you push a > different version upstream, then we'd have a merge conflict. > > Please let me know what you suggest. Those patches are queued and I have no plans to change them before submitting to Linus. When you say identical, do you mean the patches themselves or also the commit and object IDs? Traditionally I have rebased the tree before sending the pull request to minimise the changes of any merge issues and the published tree is marked for -mm only for that reason. If thats going to cause a problem I'll just check any merge works before sending the pull request and leave the tree alone from now... Cheers, Richard -- 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
