[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable

Luck, Tony tony.luck at intel.com
Tue Jun 19 17:52:14 UTC 2012

> This is also why I think we need a linux-devel branch that holds
> people's development branches. Everyone's allowed to rebase when they
> want, add acked-by's and reviewed-by's and such. This would be for
> rebasing in general. Basically, a playground to see what others think.

How much broad testing would such a tree get?  Right now we see issues
show up in mainline from patches that have been in linux-next ... but
because there isn't enough diverse testing of -next, the problems
aren't found.

Right now *my* linux-next testing is rather cursory: I try to build
a half-dozen different configurations from each tag, but only one of
those gets booted, and only very light testing occurs. I'm not sure
whether I'd be able to do much with linux-devel (e.g. adding tests for
"-mm" was always on my TODO list, but never made it to the top :-( ).

Large scale automated building and booting by companies with
resources to do this helps a bit - but such tests don't come close
to replicating the huge range of environments and workloads that
mainline users subject the kernel to.

So I fear that linux-devel would lull some people into a false sense
of security. They'll cook their patches there for a week or two, and
then dump them into linux-next when Linus announces "-rc7 is the last
release candidate", and then send a please-pull a week later. If the
patches touch some out of the mainstream area ... then they'll have
had virtually no actual testing (beyond what the developer did).


More information about the Ksummit-2012-discuss mailing list