Re: [PATCH] filesystem location based auditing
On Mon, Feb 27, 2006 at 12:24:35PM -0500, Steve Grubb wrote:
On Monday 27 February 2006 12:06, Amy Griffis wrote:
> What is the preferred way to update a patch which has already been
> merged?
In the past, we've applied patches on top of patches when they've
been out for some time. If its recent, like within a week, we've
corrected patches since there's not much that is counting on it
being a certain way. An example, we've got 2 patches against
Dustin's patch that adds contexts to syscall records.
I understand why you want to do things this way. But I don't think it
makes it very easy for someone upstream to review our list of patches.
I thought that the branches in the git tree could handle this. Would
it be possible to have a new branch that moves the inotify kernel api
patch and the audit watch patch to the end of the list?
If this isn't possible, then I'm afraid I don't understand the point
of the 'amg' branch.
Under normal circumstances this normally isn't a problem. Right
now
we have a 5 month backlog of patches that haven't gone upstream.
That represents about 17-20 individual patches. Each patch added
makes it more and more fragile to changes that upstream is making.
The functionality that you just added, the audit client, really does
stand on its own. I don't think you need to merge it with the
string2 patch.
The patch I just posted includes all of the AUDIT_WATCH functionality.
The previous patch (aka string2) only included functionality for
add/remove/listing rules. The purpose of separating this piece out
was to have something stable that would enable work on the interface
changes from the userspace side.
If the AUDIT_WATCH functionality is to be reviewed by anyone further
upstream, as I expect it to be, it should be reviewed as a single
patch. The first patch adds a chunk of code that is then removed by
the second patch. It's pointless for anyone upstream to review that
intermediate work.
This is also going to be a problem with the inotify kernel API patch,
as it needs a re-write before it can be proposed upstream.
Regards,
Amy