From: David Miller <davem@davemloft.net>
To: linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Cc: mm-commits@vger.kernel.org, linville@tuxdriver.com,
ron.rindjunsky@intel.com, sfr@canb.auug.org.au,
tomas.winkler@intel.com
Subject: Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree
Date: Tue, 13 May 2008 21:39:27 -0700 (PDT) [thread overview]
Message-ID: <20080513.213927.191790810.davem@davemloft.net> (raw)
In-Reply-To: <200805140405.m4E45oBc015343@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Tue, 13 May 2008 21:05:50 -0700
> Subject: wireless: fix "iwlwifi: unify init driver flow"
> From: Andrew Morton <akpm@linux-foundation.org>
>
> drivers/net/wireless/iwlwifi/iwl-core.c: In function 'iwlcore_init_geos':
> drivers/net/wireless/iwlwifi/iwl-core.c:323: error: implicit declaration of function 'iwlcore_init_ht_hw_capab'
>
> This (or something like it) should be folded into the base patch to avoid
> breaking bisection, please.
>
> Cc: Ron Rindjunsky <ron.rindjunsky@intel.com>
> Cc: Tomas Winkler <tomas.winkler@intel.com>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrew, you have to figure out what we're supposed to do here.
If I "fold in the patch" to avoid breaking bisection, I have to
completely rebase my tree screwing up everyone of my downstream
developers.
Or is this some patch I'm supposed to remember to fold in several
months from now, to some random changeset out of thousands, when the
merge window opens?
Neither option is tenable, and the headaches of neither are
worth it purely for the sake of bisection.
My solution to the bisection problem is to wait a day before pushing
out usually, it's a best effort thing. I do as many sanity builds as
I can, and we also hope that someone during that day might solve the
problem independantly and post a fix. That way I can fix it in my
tree locally before the tree goes public.
And I think this is the most reasonable approach.
Once I push something to my public tree, quite frankly, it's the real
deal, it's staying there, and it's a part of the permanent record.
And therefore, we'll put fixes on top.
next parent reply other threads:[~2008-05-14 4:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200805140405.m4E45oBc015343@imap1.linux-foundation.org>
2008-05-14 4:39 ` David Miller [this message]
2008-05-14 4:57 ` + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to -mm tree Andrew Morton
2008-05-14 5:15 ` David Miller
2008-05-14 12:34 ` John W. Linville
2008-05-14 17:50 ` Andrew Morton
2008-05-14 7:34 ` Winkler, Tomas
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=20080513.213927.191790810.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mm-commits@vger.kernel.org \
--cc=ron.rindjunsky@intel.com \
--cc=sfr@canb.auug.org.au \
--cc=tomas.winkler@intel.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