[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081002093213.GB4190@elte.hu>
Date: Thu, 2 Oct 2008 11:32:13 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: Mike Travis <travis@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
David Miller <davem@...emloft.net>,
Yinghai Lu <yhlu.kernel@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Jack Steiner <steiner@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/31] cpumask: Documentation
* Rusty Russell <rusty@...tcorp.com.au> wrote:
> > IMHO, an infrastructure change of this magnitude should absolutely
> > be done via the Git space. This needs a ton of testing and needs
> > bisection, a real Git track record, etc.
>
> Not yet. Committing untested patches into git is the enemy of
> bisection; if one of my patches breaks an architecture, they lose the
> ability to bisect until its fixed. If it's a series of patches, we
> can go back and fix it.
while the initial series might be rebased once or twice, beyond the 1-2
days of initial integration and testing i dont think that's true, and
i'm doing up to 3-4 bisections a day just fine, on an append-mostly
tree.
if you have trouble turning a Git tree into a bisectable tree then your
testing-fu is not strong enough ;-)
[ the only plausible danger is to architectures that are not used by
testers all that much (so that breakages can linger a lot longer
unnoticed) - but why should the other 99% of Linux users be put at a
disadvantage for them. ]
Ingo
--
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