On Wed, Dec 9, 2020 at 10:27 PM Martin Schiller <ms@xxxxxxxxxx> 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.
