All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Benny Halevy <bhalevy@panasas.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Ingo Molnar <mingo@elte.hu>,
	linux-next@vger.kernel.org, Andy Adamson <andros@netapp.com>,
	Fredric Isaman <iisaman@citi.umich.edu>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Alexander Beregalov <a.beregalov@gmail.com>,
	Subrata Modak <subrata@linux.vnet.ibm.com>,
	sachinp <sachinp@linux.vnet.ibm.com>
Subject: Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules.
Date: Thu, 23 Apr 2009 22:25:30 +0900	[thread overview]
Message-ID: <20090423132530.GA26887@linux-sh.org> (raw)
In-Reply-To: <1240491589.8240.42.camel@heimdal.trondhjem.org>

On Thu, Apr 23, 2009 at 08:59:49AM -0400, Trond Myklebust wrote:
> On Thu, 2009-04-23 at 19:29 +0900, Paul Mundt wrote:
> > 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.
> 
Nor is bantering on semantics going to change the fact that you caused a
build regression and have so far refused to even acknowledge that that is
a problem. If anyone had bothered to test the module build, this would
have shown up immediately and would have rightly been fixed before that
change was merged. Claiming that the two are completely unrelated after
the fact is rather disingenuous, and does nothing to address the process
problem.

> 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.
> 
That's a complete cop-out, if there had been no export at all how would
you have proceeded? How is this situation any different?

I am willing to monitor my builds regularly and send out trivial patches
to fix whatever ends up breaking, but I do expect people who have caused
regressions to take these matters seriously rather than sweep them under
the carpet and pretend like they either don't exist or are somehow
someone else's problem.

Any tree that causes a regression should simply be dropped until it gets
it sorted out, as it's abundantly obvious that people aren't even
prepared to do the bare minimum to keep things working after they've been
pulled from.

  parent reply	other threads:[~2009-04-23 13:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-16  3:07 [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules Paul Mundt
2009-04-16  8:11 ` Benny Halevy
2009-04-23  6:50   ` Paul Mundt
2009-04-23 10:12     ` Benny Halevy
2009-04-23 10:29       ` Paul Mundt
2009-04-23 12:59         ` Trond Myklebust
2009-04-23 13:18           ` Benny Halevy
2009-04-23 13:25           ` Paul Mundt [this message]
2009-04-23 13:59             ` Trond Myklebust
2009-04-23 14:12               ` Paul Mundt
2009-04-23 16:38                 ` Trond Myklebust
2009-04-26 12:49                   ` Rusty Russell
2009-04-26 16:42                     ` Ingo Molnar
2009-04-26 17:29                       ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090423132530.GA26887@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=a.beregalov@gmail.com \
    --cc=andros@netapp.com \
    --cc=bhalevy@panasas.com \
    --cc=iisaman@citi.umich.edu \
    --cc=linux-next@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=sachinp@linux.vnet.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --cc=subrata@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.