Re: Latest for-4.14

Leon Romanovsky
2017-07-29T09:23:16Z

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

On Fri, Jul 28, 2017 at 03:42:52PM -0400, Doug Ledford wrote:
> On 7/28/2017 3:29 PM, Leon Romanovsky wrote:
> > On Fri, Jul 28, 2017 at 12:54:56PM -0400, Doug Ledford wrote:
> >> On Fri, 2017-07-28 at 07:32 +0300, Leon Romanovsky wrote:
>
> >> officially landed in their repo (unless there are review issues or
> >> build failures that kick it back out), so I don't know why you would
> >> expect different from me, but it's not gonna happen.
> >
> > I didn't expect anything different from you. What I expected from you is
> > to take a look on one patchset, decide go/no go, add to your branch, push
> > to github and 0-build (it very good in queuing jobs),
>
> Right now 0day is taking 10-13hours to give me results. If people are
> queueing up test runs for every single patch (or small patch series),
> then no wonder it's taking so long. That's horribly inefficient. There
> is enough stuff for me to look at that I'm batching it up, applying
> multiple series to a specific branch, and then doing the build testing
> at the end for the whole group. If I know I'm looking at 10 small patch
> series in a given day, then I doubt you will ever get me to send them
> all separately to 0day as that sort of behavior is likely precisely why
> it's taking 10+ hours to get results right now. If people *didn't* do
> that, then the results might get in much sooner.

It now explains why you are getting results so late.

Doug,
The 0-day service runs their checks on every commit which doesn't exist
in its database (it checks by hash) and posts results for latest commit
without relation to success/failure. For intermediate commits, it posts
result on failure only.

So your batch posting is the reason why you are not getting results
immediately and it is not relevant for "efficiency". One of the goals
for the 0-day service is to support bisectable commits, by ensuring
compilation at least.

Thanks

>
> > announce and so on
> > till all patches are tested and it can be forwarded to k.o.
> >
> > Sorry, if I expected too much.
> >
> >>
> >>> As I said more than once, I'm fine with sequential work, I'm fine
> >>> with
> >>> the fact that not all my code is accepted, I'm fine with scheduled
> >>> delays, but I'm not fine with silence.
> >>
> >>
> >>
> >> --
> >> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> GPG KeyID: B826A3330E572FDD
> >> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
> >>
>
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG Key ID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]