On Thu, Apr 16, 2009 at 11:11:02AM +0300, Benny Halevy wrote:
> On Apr. 16, 2009, 6:07 +0300, Paul Mundt <lethal@xxxxxxxxxxxx> wrote:
> > Caught with the sh allmodconfig:
> >
> > ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
> > make[2]: *** [__modpost] Error 1
> > make[1]: *** [modules] Error 2
> > make: *** [sub-make] Error 2
> >
> > find_last_bit.o is currently built with lib-y, which ends up breaking
> > the nfs module build after the ("nfs41: free slot") commit. Move it
> > to obj-y so the EXPORT_SYMBOL() actually has some effect.
> >
> > Signed-off-by: Paul Mundt <lethal@xxxxxxxxxxxx>
> > Cc: Benny Halevy <bhalevy@xxxxxxxxxxx>
>
> ACK. and thanks!
>
> FYI, Fred's original patch can be found here:
> http://patchwork.kernel.org/patch/14572/
>
> It is also queued in the linux-pnfs tree:
> http://git.linux-nfs.org/?p=bhalevy/linux-pnfs.git;a=commitdiff;h=1e3a7552d9de2ba101b76deed99605f0145fc4d5
> but I haven't submitted it to Trond since I expected
> it to get upstream (and to -next) via linux-kbuild.
>
> Trond, would you like to pull this change to your nfsv41 branch?
> (should appear before "nfs41: free slot" as Paul noticed)
>
Ok, so we have two different trivial patches for fixing the same thing,
and a week later it is still broken.
I realize it is a trivial patch, but it does break builds. If folks
aren't going to take these sorts of things more seriously, then their
tree should be dropped after a grace period (say 2 days or so).
Beyond that, it doesn't seem like -next has any sort of coherent policy
for dealing with trivial patches. If the emphasis is on the tree that
introduced the regression to deal with it, then trees need to be
aggressively dropped when these things go unfixed.
Having builds broken for a week for an issue that has been spotted and
fixed by several people is simply unacceptable.
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
