Re: [PATCH] firmware/efi: export a routine to retrieve efi-variablesby GUID

From: Dan Williams
Date: Fri Mar 18 2011 - 21:16:04 EST


On 3/18/2011 5:22 PM, Greg KH wrote:
On Fri, Mar 18, 2011 at 04:10:10PM -0700, Dan Williams wrote:
I needed all patches in linux-next _before_ the merge window opened to
be able to accept it.

Yes, I know, and as dmaengine maintainer I also hate being ambushed by
last minute patches, but now I am unfortunately one of those annoying
people on the other side of the coin.

Then you should know better than to try to go around the well-known
rules :)

Yes...

/me about to push his luck

...I also know the rules can sometimes be bent:

$ git describe --contains 9d200153
v2.6.35-rc2~14^2~15

commit 9d20015391dfc47f6371492925cc0333ac403414
Author: Stepan Moskovchenko <stepanm@xxxxxxxxxxxxxx>
Date: Wed May 19 11:03:30 2010 -0700

Staging: add MSM framebuffer driver

I see you got flamed for that:
"I pulled, but quite frankly, I don't want to see this kind of pull request again. There's just no _point_.

I'll take new drivers outside the merge window, but there has to be some
_reason_ for them. See the whole SCSI discussion a few merge windows ago. The new driver needs to improve the life of somebody to the point where I want to feel that there is a _reason_ for pulling it outside the merge window.

These drivers? Not so much. Not even f*cking close.

In other words: tell me why the new drivers couldn't just have waited for the next merge window? Really?"

As Jeff pointed out:
"It seemed like this was turning into another driver that would get held outside the kernel until it's "perfect." If that is the case, Linus has also made it clear we should get drivers for high volume, shipping hardware into the kernel, even if its staging, if the alternative is to deny users the driver."

So yes, we are targeting that exception. I'm up for taking the heat directly if you want... because the pull request will need to backed up with justification.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/