Messages in this thread | | | From | Xie He <> | Date | Thu, 10 Dec 2020 01:31:50 -0800 | Subject | Re: [PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling |
| |
On Wed, Dec 9, 2020 at 10:27 PM Martin Schiller <ms@dev.tdt.de> wrote: > > > Hi Martin, > > > > When you submit future patch series, can you try ensuring the code to > > be in a completely working state after each patch in the series? This > > makes reviewing the patches easier. After the patches get applied, > > this also makes tracing bugs (for example, with "git bisect") through > > the commit history easier. > > Well I thought that's what patch series are for: > Send patches that belong together and should be applied together. > > Of course I will try to make each patch work on its own, but this is not > always possible with major changes or ends up in monster patches. > And nobody wants that.
Thanks! I admit that this series is a big change and is not easy to split up properly. If I were you, I may end up sending a very big patch first, and then follow up with small patches for "restart request/confirm handling" and "add/remove x25_neigh on device-register/unregister instead of device-up/down". (The little change in x25_link_established should belong to the first big patch instead of "restart request/confirm handling".)
But making each patch work on its own is indeed preferable. I see https://www.kernel.org/doc/html/latest/process/submitting-patches.html says: When dividing your change into a series of patches, take special care to ensure that the kernel builds and runs properly after each patch in the series. Developers using git bisect to track down a problem can end up splitting your patch series at any point; they will not thank you if you introduce bugs in the middle.
| |