All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: mrmacman_g4@mac.com, ak@suse.de, hch@infradead.org,
	jeffm@suse.com, linux-kernel@vger.kernel.org,
	kernel-bugzilla@luksan.cjb.net
Subject: Re: quality control
Date: Wed, 8 Feb 2006 09:45:22 +0100	[thread overview]
Message-ID: <20060208084522.GC4338@suse.de> (raw)
In-Reply-To: <20060207144433.6bdc4f66.akpm@osdl.org>

On Tue, Feb 07 2006, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > Look, it's really simple: lets say I make a change that has to do with
> > PM, you do a quick compile test with and _without_ PM just to check you
> > didn't screw anything up with that change. You change reiserfs acl
> > stuff, you do a quick compile test with and without that configured.
> > 
> > It's a pretty standard procedure, and contrary to what you think, it
> > _is_ required before submitting a patch. No one is asking anyone to
> > check all possible configure options, but the interesting data set is
> > typically extremely easy to guess looking at a change.
> 
> <rofl>
> 
> bix:/usr/src/op> find patches -name '*build-fix*' | wc -l
>     533
> 
> bix:/usr/src/op> find patches -name '*fix.patch' | wc -l
>    5109
> 
> A lot of people don't make the slightest effort.  But it's not a big
> problem, really.  Silly build errors are reported early and are almost
> always trivial to fix.  The major drawback is that they can wreck a -mm
> release for many testers.

That's precisely the problem, it may be really simple to fix but often
will stop people from testing.

Your fix count probably isn't totally accurate either, I bet a lot of
these are fixups due to conflicts with other patches. I'm talking about
the fact that someone sends Linus a patch which doesn't compile for the
case you could (and should) have trivially checked. A little edumacation
never hurt :-)

-- 
Jens Axboe


  reply	other threads:[~2006-02-08  8:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <43E64791.8010302@namesys.com>
     [not found] ` <43E6521F.5020707@suse.com>
2006-02-06  3:15   ` quality control Hans Reiser
2006-02-06  3:39     ` Kyle Moffett
2006-02-06  9:09       ` Jens Axboe
2006-02-06  9:15       ` Martin Mares
2006-02-06 11:09       ` Andi Kleen
2006-02-06 13:31         ` Kyle Moffett
2006-02-06 13:44           ` Jens Axboe
2006-02-07 22:44             ` Andrew Morton
2006-02-08  8:45               ` Jens Axboe [this message]
2006-02-06 19:27         ` Olaf Hering

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=20060208084522.GC4338@suse.de \
    --to=axboe@suse.de \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=hch@infradead.org \
    --cc=jeffm@suse.com \
    --cc=kernel-bugzilla@luksan.cjb.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrmacman_g4@mac.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.