CODEWITHSUNDEEP
gitlinux-kernel
tangrs
tangrs

Reputation: 9940

Submitting huge patchset to mailing list

I have a Linux repo with support for a new ARM platform that I'd like to post onto the ARM kernel dev mailing list to get some feedback and hopefully, eventually mainlined. Unfortunately, there's a lot of code and git format-patch spits out about 100 patch files.

I read it's best to group them together into logical changes but for a new ARM platform, each part is just as important as the next. The most I could do is probably separate basic platform support code from driver code.

In addition, my earlier commits has really vague commit messages like fixed reboot code or misc fixes which I'd rather not be included in the patchset.

What would be the best way to get my changes across without bombing the mailing list? Should I squash it into one, huge, patch? Somehow, I don't think sending 100 patch files will give a good first impression either.

Cheers,

Upvotes: 2

Views: 94

Answers (1)

jleahy
jleahy

Reputation: 16895

I'd recommend you do an interactive rebase against the current mainline kernel (that would be v3.8 at the moment). This would look something like the following:

git rebase -i origin/v3.8

Where possible squash relevant commits together, for example you should probably have one commit for each driver and one commit for each logical part of the core code, it's ok if those are dependent on each other, although it shouldn't be cyclic. You don't need to preserve all your bug-fixes from during development, the goal is to make the patches easy to understand and integrate, not have them tell a historically accurate story.

If you need to split existing commits you can choose edit and then do a git add -p, which will allow you to select diff hunks interactively and commit them one at a time (after this you can always go back to reorder and squash where necessary).

Once you've done this you should have a patch-set that'll be a lot easier for people to understand (and hopefully with useful comments). I'd suggest you generate a patchset for the core part (ie. 1/n, 2/n, 3/n...), excluding the drivers, and submit that first. Once you've dealt with that you can start pushing the drivers.

Upvotes: 2

Related Questions