[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
fengguang.wu at intel.com
Thu Jun 21 03:43:26 UTC 2012
On Wed, Jun 20, 2012 at 05:19:46PM +0000, Luck, Tony wrote:
> > Automated tests on multiple configs are done in linux-next, but by the
> > time they reach linux-next, it might be too late.
> This is why I suggested that "-rc5" should be declared as the rebase
> deadline for trees feeding into linux-next ... and that maintainers
> should be ENCOURAGED TO REBASE for any issue where it makes sense.
> It is common for build problems to show up with combinations of
> CONFIG options that were not tested by the submitter. Some
> maintainers will do the right thing (IMHO) and fold the fix
> for problems into the original patch series so we do not have
> a bisection break. Others have seen the "Don't rebase" flames
> that Linus throws out from time to time and have taken that to
> mean that every rebase is evil - those maintainers will tack the
> fix on the top of their tree ... potentially far from the commit
> that caused the problem.
> I don't think that rebasing should cause significant problems for
> linux-next ... it is a fresh merge of all the source trees each
> day on top of a moving base of where Linus' tree happens to have
> moved to.
>  we have far too many config options for this to ever be solved:
> $ make allyesconfig
> $ grep -c CONFIG .config
> Even those people with h/w that does 25,000 kernel builds per day can't make
> any dent in the full set of all possible CONFIG combinations.
Heh, it could be much better than the global perspective ;-)
In fact it's the config options that are related to the current commit
that matters. So if one commit could be impacted by 5 config options,
the test matrix would be 2^5=32 combinations. So, I choose (and can
only afford) to build test ~30 configs for each commit, while happily
leaving the extra tests for the commits that depend on more options to
someone that run 1000 randconfigs on the whole linux-next tree.
Strictly speaking, 32 randconfigs may only cover a small fraction of
the full 32 combination space. That could be something improvable.
More information about the Ksummit-2012-discuss