[Ksummit-discuss] Nominating Fengguang Wu - 0-day

[Luis R. Rodriguez]

On Fri, Jul 29, 2016 at 08:09:12AM +0800, Fengguang Wu wrote:
> On Fri, Jul 29, 2016 at 01:33:27AM +0200, Luis R. Rodriguez wrote:
> >On Fri, Jul 29, 2016 at 07:07:13AM +0800, Fengguang Wu wrote:
> >>btw, maybe some maintainers are already informed: 0-day statistics
> >>show that ~60% errors can be reported in 2 hours, ~90% errors are
> >>reported in 24 hours and there are 1% errors reported after 1 week.
> >
> >If one were to take 0-day code an slap it on some internal big-iron
> >server, and prioritize work for a few developers (say SUSE would do
> >this for its developers) do you expect the turnaround time for
> >reports would be faster if we had bigger-meaner hardware ? These
> >days actually would like to get results back in a few minutes
> >for 90% of errors so wondering how / if others have taken on
> >0-day internally and made it faster by beefing up the hardware.
> 
> I'd suspect roughly the same timing given powerful servers but still
> with reasonable cost considerations.

Interesting, thanks. Let's say I still want to, where is the code?

> Intel pretty values the 0-day service and backs it up with 12 parallel
> build servers, including 4 4S Xeon machines. Since we do merged tests,
> one may assume most of the servers are working parallel for his code
> whenever he does a git push. Kernel hackers can feel free to push
> frequently because the extra pushes are virtually cost free -- the
> build workers are working cyclicly on latest merged code anyway.

Awesome thanks! I recently ran into the situation where I may have
run into what seems to be a binutils (ld) bug and I want to verify
if it is only associated to an odd-ball architecture, I have 2 kconfig
entries I know I want tested on all architectures. In the future it
may be nice to be able to suggest a given set of kconfig entires one
wants as base for all architectures. This may need something like
kconfig-sat though [0].

[0] https://kernelnewbies.org/KernelProjects/kconfig-sat

> To take free ride of that restless horse, it'd be good to push small
> topic branches on latest RC kernels, which will have better chances
> to merge and play well with others code.

How about linux-next ?

  Luis