Re: [fwd] Re: + git-audit-master-build-fix.patch added to -mm tree
On Fri, Mar 03, 2006 at 10:25:48AM -0500, Alexander Viro wrote:
On Fri, Mar 03, 2006 at 06:33:42AM -0500, Steve Grubb wrote:
> I think Amy's patches fall into this same category, meaning they
> need to be run in the lspp kernel first to make sure we agree that
> they meet our needs before sending on to a larger community.
>
> The string interface patches have had enough run time in lspp
> kernel that they can be moved to -mm tree. As a matter of fact,
> some of Dustin's work depends on these patches and his is ready
> to go into -mm tree, too (including the leak patch).
[..]
> The only controversial work is the patches that touch inotify
and
> Jason's performance patch. I'd feel better if they get testing in
> lspp kernel first.
IMO Jason's stuff is OK. inotify, OTOH, (a) conflicts with other
stuff in -mm and (b) is not ready for any testing, period. Version
posted last week would deadlock instantly and that chunk is _the_
reason for previous inotify-affecting patch. Besides, Amy asked to
move those to the end of queue, so that she could replace them with
convenience. Which is what had been done...
I'm still not sure what to do with the string patch #2 - right now
it's in amg.b2; if Amy is OK with moving it to main branch, I'll do
that and Dustin's patches will follow immediately.
There shouldn't be any dependencies on the string #2 patch. All of
the interface changes should be contained in the string #1 patch. If
this is not the case, point me to the specific dependency and I'll fix
it.
Separating the string #1 and string #2 patches did uncover a problem
I'd forgotten about. The string #1 patch introduces a new function as
part of the interface changes. Because it doesn't have a caller, it
generates build warnings, which akpm fixed in -mm by removing the
function.
I'm not sure removing the function is the right thing to do; it seems
we might as well remove the whole patch in that case.
Would anyone have advice on how to properly introduce new interfaces
that may not yet have callers?
Thanks,
Amy