Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1385564
| From | Fengguang Wu <fengguang.wu@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC][PATCH 00/31] implement atomic_fetch_$op |
| Date | 2016-04-23 05:30 +0200 |
| Message-ID | <rqWqB-4BS-1@gated-at.bofh.it> (permalink) |
| References | <rqFSN-8hs-3@gated-at.bofh.it> <rqFSQ-8hs-43@gated-at.bofh.it> <rqIQG-234-5@gated-at.bofh.it> <rqO9I-6yL-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Apr 22, 2016 at 09:35:06PM +0300, Kalle Valo wrote: > Fengguang Wu <fengguang.wu@intel.com> writes: > > >> OK, weirdness. I received the "BUILD SUCCESS" email without any arm64 > >> builds listed, but I just received a build bot email telling me the > >> arm64 build was borked (which I know it is). > > > > Sorry, that may happen because even though most errors will be > > detected in the first hour or before the BUILD SUCCESS/DONE > > notification, the build/boot/performance tests for a particular branch > > may continue for days, during the time test coverage keeps growing. > > Which means it's possible to receive a build failure after receiving > > BUILD SUCCESS notification. > > > > In particular, 0-day bot classify 500+ kconfigs into 2 priority lists: > > > > P1: 100+ realtime priority kconfigs which should be finished before sending > > out BUILD SUCCESS notification > > > > P2: 400+ background priority kconfigs which may take hours to days to finish > > > > That split is a tradeoff between timeliness and completeness. It turns > > out to work well as long as we choose the suitable P1 list. > > > > So the more accurate interpretation of "BUILD SUCCESS/DONE" would be: > > 0day bot is working on your tree (no worry about out-of-service) and > > reached a major milestone. > > Thanks, this is very useful information. But would it be also possible > to get a report about the P2 completion (or failure)? Good question! I'm not sure people would care (or even be confused) about a report that arrive after days, however based on some statistic data we may find the suitable time to wait for possible error reports. The past reports show that about 60% errors are reported in 2 hours, 90% errors are reported in 24 hours and there are 1% errors reported after 1 week. So developers may reasonably wait for 1 day before sending out patches. Thanks, Fengguang
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Peter Zijlstra <peterz@infradead.org> - 2016-04-22 11:50 +0200
Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Fengguang Wu <fengguang.wu@intel.com> - 2016-04-22 15:00 +0200
Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Will Deacon <will.deacon@arm.com> - 2016-04-22 15:10 +0200
Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Peter Zijlstra <peterz@infradead.org> - 2016-04-22 16:30 +0200
Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Fengguang Wu <fengguang.wu@intel.com> - 2016-04-23 04:00 +0200
Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Kalle Valo <kvalo@codeaurora.org> - 2016-04-22 20:40 +0200
Re: [RFC][PATCH 00/31] implement atomic_fetch_$op Fengguang Wu <fengguang.wu@intel.com> - 2016-04-23 05:30 +0200
csiph-web