[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
paul.gortmaker at windriver.com
Thu Jun 21 18:58:45 UTC 2012
On 12-06-20 06:17 PM, Stephen Rothwell wrote:
> On Wed, 20 Jun 2012 10:28:28 -0500 Jason Wessel <jason.wessel at windriver.com> wrote:
>> What is not clear to me is if the linux-next infrastructure even has
>> close to the kind of cycles that are required to prove something
>> bisects and build with all the permutations of a .config to fully
>> build test a patch. Having a metric and notifications for bisection
>> and "intelligent .config" would hopefully improve quality.
> It is clear that linux-next should not be doing (the vast majority) of
> that. Bisectability is property of each tree independently so should be
> ensured by the developer and maintainer. All linux-next is capable of
> doing is (hopefully) catching problems caused by the interactions between
> trees. The build problems that irritate me are the ones that exist
> entirely within a single tree - and I get way more of those than I should.
I think another contributing factor is that linux-next is
most likely the 1st time many commits are being exposed
to multi arch builds. Things like <linux/foo.h> is implicitly
present in bar.c for x86 but not ARM, or a Kconfig entry for
an arch specific driver is missing an explicit arch depend
statement type bugs. But with the prebuilt toolchains on
kernel.org, the reality is anyone can cross compile anything
with minimal effort.
> The most obvious thing to be done is that developers should be build and
> boot testing with and without CONFIG options set that clearly influence
> their patches. They have the best idea just what those are and most
> likely the hardware as well. i.e. more care and less haste right from the
> start ...
> Ksummit-2012-discuss mailing list
> Ksummit-2012-discuss at lists.linux-foundation.org
More information about the Ksummit-2012-discuss