Message-Id: <20080513215737.fe1bdebd.akpm@linux-foundation.org>
Date:	Tue, 13 May 2008 21:57:37 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
Cc:	linux-kernel@...r.kernel.org, linville@...driver.com,
	ron.rindjunsky@...el.com, sfr@...b.auug.org.au,
	tomas.winkler@...el.com, git@...r.kernel.org
Subject: Re: + wireless-fix-iwlwifi-unify-init-driver-flow.patch added to
 -mm tree

On Tue, 13 May 2008 21:39:27 -0700 (PDT) David Miller <davem@...emloft.net> wrote:

> From: akpm@...ux-foundation.org
> Date: Tue, 13 May 2008 21:05:50 -0700
> 
> > Subject: wireless: fix "iwlwifi: unify init driver flow"
> > From: Andrew Morton <akpm@...ux-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@...el.com>
> > Cc: Tomas Winkler <tomas.winkler@...el.com>
> > Cc: John W. Linville <linville@...driver.com>
> > Cc: Stephen Rothwell <sfr@...b.auug.org.au>
> > Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> 
> Andrew, you have to figure out what we're supposed to do here.

Well someone does ;)

> 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.

What goes into Linus's tree is there for ever and I do think that all
the short-term things we do should be built around making the permanent
record as good as possible.

This is a(nother) case where a toolchain/process problem is forcing us
to do something which we don't want to do.  In an ideal world we should
tell the git developers "we want x, please" and hopefully they can give
it to us.  Because right now, we're having to work around shortcomings
in git and we are producing a lesser product as a result of this.  A tool
should follow the way in which humans want to work, not vice versa.

Short-term...  dunno.  Perhaps you could have a two-weekly
broadly-announced rebase in which you integrate all these dribs and
drags back into their proper place?  Commit them with some well-known
identifier in the title so that they can all be located when that time
comes?

If you announce such a rebase a day or so beforehand then all the guys
who feed into you could get their stuff merged up into your tree to
minimise their pain when the rebase happens, perhaps.

(That being said, this particular no-compile isn't a huge problem - it
can be worked around with a Kconfig change.  But that isn't generally
the case)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists