How to handle patches that require regular regeneration

[David Howells]

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
--
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/