On Wed, 2018-06-13 at 12:19 -0400, Paul Moore wrote: > On Wed, Jun 13, 2018 at 12:04 PM, Joe Perches <joe@xxxxxxxxxxx> wrote: > > On Wed, 2018-06-13 at 11:49 -0400, Paul Moore wrote: > > > 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. > > > > No. History shows with high certainty that splitting > > patches like this across multiple subsystems of a primary > > subsystem means that the entire patchset is not completely > > applied. > > I think that is due more to a lack of effort on the part of the patch > author to keep pushing the individual patches. Nope. Try again. Resistance to change and desire for status quo occurs in many subsystems. > > It's _much_ simpler and provides a generic mechanism to > > get the entire patch applied to send a single patch to the > > top level subsystem maintainer. > > I understand it is simpler for you, but it is more difficult for everyone else. Not true. It's simply a matter of merge resolution being pushed down where and when necessary. See changes like the additions of the SPDX license tags. > Further, where the LSMs are concerned, there is no "top level > subsystem maintainer" anymore. SELinux and AppArmor send pull > requests directly to Linus. MAINTAINERS-SECURITY SUBSYSTEM MAINTAINERS-M: James Morris <jmorris@xxxxxxxxx> MAINTAINERS-M: "Serge E. Hallyn" <serge@xxxxxxxxxx> MAINTAINERS-L: linux-security-module@xxxxxxxxxxxxxxx (suggested Cc:) MAINTAINERS-T: git git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git MAINTAINERS-W: http://kernsec.org/ MAINTAINERS-S: Supported MAINTAINERS:F: security/ MAINTAINERS- If James is not approving or merging security/selinux or security/tomoyo then perhaps the F: entries could be augmented with appropriate X: entries or made specific by using specific entries like: F: security/* F: security/integrity/ F: security/keys/
