How to handle patches that require regular regeneration

Hi Linus,

Having observed your recent complaint:

http://article.gmane.org/gmane.linux.kernel/1173804

"But best would be if it was actually tested, and had actually been in -next for a week. That is *especially* true when you send me a pull request late in the merge window."

And I have a question as how you might prefer to handle some classes of patchset.

I have a patchset that needs regular regeneration as it scriptually alters all the header files that are exported to userspace as a first step in cleaning up the headers preparatory to sorting out the inclusion recursion issues.

http://git.infradead.org/users/dhowells/linux-headers.git/shortlog/refs/heads/uapi-split

What's the best way to handle a patchset like this?

Do I point Stephen at a script and ask him to run that to create a new tree for him to pull into linux-next, knowing that you probably won't be able to pull the tree directly anyway?

I agree that including it in linux-next would be good, but it potentially sticks a large burden on Stephen:-/

I know the patches compiled with allyesconfig for x86_64, i386 and MIPS with some disabling in the configuration to handle stuff that was failing anyway.

I've done my best to make sure that the patches don't lose any content, but occasionally the scripts have to be coached as to the right place to make a split.

David