On Apr. 23, 2009, 15:59 +0300, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: > On Thu, 2009-04-23 at 19:29 +0900, Paul Mundt wrote: >> On Thu, Apr 23, 2009 at 01:12:54PM +0300, Benny Halevy wrote: >>> On Apr. 23, 2009, 9:50 +0300, Paul Mundt <lethal@xxxxxxxxxxxx> wrote: >>>> 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. >>> Paul, that's a valid point but I don't set these polices. >>> Trond suggested to just commit this to 2.6.30 >>> and I asked Rusty's Ack here: >>> http://lkml.org/lkml/2009/4/21/489 >>> >>> Like I said there, I'm not sure who to send this patch to. >>> Ingo? >>> >> I was under the impression that a tree that caused a build regression >> would be dropped until it had it sorted out, but that seems to be more >> the exception than the rule. >> >> -next is good at finding bugs in build configurations folks haven't >> considered, which should serve as a pretty good platform for getting >> those types of fixes merged quickly, whether it be in to the tree that >> caused the regression or -next directly. >> >> Unfortunately it seems like build regressions are more of an afterthought >> than a show stopper. I count at least 3 on the sh builds in the last >> couple weeks that are all averaging a week or longer to unbreak, while >> patches have been available almost immediately. > > In this case, the tree in question is exposing a bug that already exists > in mainline; a function that is explicitly labelled as being exported > for use by arbitrary modules, and yet isn't being compiled into the > kernel. Shooting the messenger isn't going to fix that. > > In any case, this patch does not belong in the NFS tree since it touches > generic library code, not NFS code. Benny, if nobody else wants to > shepherd it, then just send it directly to Linus. Will do. Regardless, Paul's observation seems valid. I wonder if linux-next should have a branch or pull a tree holding trivial fixes fitting no other specific tree... Benny > > Trond -- 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
