On Mon, Oct 16, 2017 at 4:47 PM, Steve Grubb <[email protected]> wrote: > On Monday, October 16, 2017 3:15:03 PM EDT Paul Moore wrote: >> >> > The audit subsystem allows selecting audit events based on watches for >> >> > a particular behavior like writing to a file. A lot of syscalls have >> >> > been added without updating the list. This patch adds 2 syscalls to the >> >> > write filters: fallocate and renameat2. >> >> > >> >> > Signed-off-by: sgrubb <[email protected]> >> >> >> >> Reviewed-by: Richard Guy Briggs <[email protected]> >> > >> > Please add a link to the issue number in the body of the patch >> > description: >> > >> > See: https://github.com/linux-audit/audit-kernel/issues/67 >> >> FWIW, I don't really care if the upstream issue is included in the >> submitted patch; if you want to include it - great, if you don't - >> that's fine too. The commit description needs to stand on its own, >> regardless of any external issue trackers, mailing lists, etc. > > I honestly don't know what the protocol is here. Should I resend the patch > with that or is that fixed up in the merge process? The reason I ask is on the > user space side I never make anyone resend a patch unless its grossly wrong or > incomplete. I just fix it. But that's what I do and not everyone works that > way.
It really depends on the situation, there is no strict rule to follow, although if I'm expecting you to respin a patch I'll let you know. In the comment above I said that I didn't care either way (about the GH issue), that means you don't need to worry about it. I also said I'd fixup your sign-off line when I apply the patch, there is no need to respin, although you do need to fix that from this point on (future new patches as well as any I ask you to respin). In general, heavy editing by the maintainer is discouraged; exceptions are made for merge fuzz, trivial fixes, agreed upon tweaks, etc. There is also a bit of a human factor if we are truly honest, but I try to minimize that as much as possible (am I in a good mood and wiling to fix the code? has the contributor annoyed me lately? etc.). At the end of the day, every maintainer is a bit different. -- paul moore www.paul-moore.com -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
