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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox