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

[Fengguang Wu <fengguang.wu@intel.com>]

On Thu, Jul 28, 2016 at 10:00:11PM -0400, Steven Rostedt wrote:
>On Fri, 29 Jul 2016 07:07:13 +0800
>Fengguang Wu <fengguang.wu@intel.com> wrote:
>
>
>> Such a status web page would be similar to the email notification
>> with no much extra contents, except that it's always there for your
>> polling. If that'd be valuable to you and some few other developers,
>> I'd be glad to push forward the Web UI feature.
>>
>> I need your understand that there are severe limitations what useful
>> contents we can provide due to the nature of merge-test-bisect. For
>> example, there will be no build logs specific for your branches/commits
>> because the extensive build tests are possible only because your code
>> are tested together with a large number of random others. For the same
>> reason there will be no error/warnings available for browsing before
>> the noisy error/warnings are bisected down. If we expose the unclassified
>> noisy error messages and encourage developers to browse through them
>> and do a guess work "are they likely caused by my commits?", we may be
>> wasting the highly valued developer time.
>>
>> 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.
>>
>> As we extend test coverage aggressively, there are no longer clear
>> moment that we can claim all tests for a branch are complete. The
>> actual build/boot tests may well go on for over a week, covering
>> thousands of kconfigs. The more time consuming functional/performance
>> tests may go on for a month. That's made possible and cost effective
>> thanks to the merge-test-bisect methodology.
>>
>> So the safe bet is to wait for 1 day's tests before sending out patches.
>> The BUILD SUCCESS notification serves as an indication 0-day robot is
>> not sleeping through. My personal style suggestion would be to stay
>> relaxed, take time and avoid polling. :)
>>
>
>I'm signed up to the BUILD_SUCCESS notification, but there's been times
>where they never showed up, probably due to the issues you mentioned.
>What would be really useful, is just a status page of what commit has
>been pulled into testing, and if it finished successful or not. It
>doesn't need to display anything else but where it is in the test.
>
>For example, if there's a web page of my git repo, I could see:
>
> branch ftrace commit SHA1-A - finished failed
> branch ftrace commit SHA1-B - finished success
> branch ftrace commit SHA1-C - running
>
>Something like that, where I can see that your tests have picked up my
>lasted push, and if I should be waiting for an email notification or
>not.
>
>Make sense?

Yes that makes good sense. A more structured layout could be

trace
├── for-next
│   ├── 97f8827a8c7963756ae7d3ee898675b4667eca73
│   └── HEAD -> 97f8827a8c7963756ae7d3ee898675b4667eca73
└── ftrace
    ├── core
    │   ├── 501c2375253c0795048f48368e0b3e8b2f6646dc
    │   ├── 78aebca2c955c1c5aeb48e12645e13fe3c3461f2
    │   ├── 7fa8b7171a638ad896acabd9a17183b75b70aeb4
    │   ├── 8329e818f14926a6040df86b2668568bde342ebf
    │   ├── de9be5961936523e6cc3a1358b166e4efb42595b
    │   ├── fc54f5a288feb132d089404ef5748725ac669a5c
    │   └── HEAD -> 78aebca2c955c1c5aeb48e12645e13fe3c3461f2
    └── urgent
        ├── 0ded5174e976e2b2a354fe38abf1ebf4492c6dc3
        ├── 90d6c42c7766fe63c724a6ec7758a85b6231b08b
        └── HEAD -> 90d6c42c7766fe63c724a6ec7758a85b6231b08b

Each end node contains log messages showing all the progresses that
have been made.

If necessary, symlinks (like HEAD commit's patch-file-name) could be
created at top level to make it more convenient to navigate. Such
symlinks can be auto deleted after 1 day (when people are less
unlikely to look at its status).

Thanks,
Fengguang