On Tue, Jun 12, 2018 at 8:29 PM, Joe Perches <joe@xxxxxxxxxxx> wrote: > On Tue, 2018-06-12 at 17:12 -0400, Paul Moore wrote: >> Joe, in general I really appreciate the fixes you send, but these >> patches that cross a lot of subsystem boundaries (this isn't the first >> one that does this) causes unnecessary conflicts in -next and during >> the merge window. Could you split your patches up from now on please? > > Sorry. No. Merge conflicts are inherent in this system. Yes, merge conflicts are inherent in this system when one makes a single change which impacts multiple subsystems, e.g. changing a core kernel function which is called by multiple subsystems. However, that isn't what this patch does, it makes a number of self-contained changes across multiple subsystems; there are no cross-subsystem dependencies in this patch. You are increasing the likelihood of conflicts for no good reason; that is why I'm asking you to split this patch and others like it. > There is just no good way to do this as sending a set > of per subsystem patches guarantees partial application > of the entire set. Please explain why all of these changes need to be made at the same time? Looking quickly at the patch it would appear that each chunk of the patch could be applied independently and the kernel would still build and operate correctly. I'm not suggesting that you decompose this patch with that level of granularity, that would be silly, but splitting this patch (and many of the others you tend to submit) at subsystem boundaries should be possible. Further, as one could see from the responses of the other LSM maintainers, splitting this patch is not just possible, it is desirable. > If you prefer, each sub-subsystem maintainer, at > whatever granularity desired, could apply the patch > to the appropriate subsystem by using > "git am --include=<subsystem_path>". Or you could split the patch up by subsystem before posting, like so many other developers do already. -- paul moore www.paul-moore.com
