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

[Bjorn Helgaas <bhelgaas@google.com>]

On Thu, Jul 28, 2016 at 7:09 PM, Fengguang Wu <fengguang.wu@intel.com> 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.
>
> 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.
>
> 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.

I'm interested in learning more about how this works.  I typically
base all my topic branches on -rc2 or so, no matter where we are in
the cycle, because it makes it easier to rebuild my "next" branch if I
discover a problem and want to amend something.  But maybe this
consumes more 0-day cycles than necessary.

I second the desire for a web page of status.  Sometimes things seem
to get lost or delayed and I hate to bug Fengguang unnecessarily.

I typically push a topic branch and wait for BUILD_SUCCESS before
merging into my "next" branch.  I do this manually by watching for the
email, but maybe it could be scripted if there were a way to query
"build status for SHA-1".