On Sep 4, 2019, at 11:49 am, Adrian Perez de Castro <aperez@igalia.com> wrote:
Hello Aakash, WebKittens,
On Thu, 29 Aug 2019 18:01:56 -0400, Aakash Jain <aakash_jain@apple.com> wrote:
I want to update everyone with the further improvements I have made to new EWS. As always, please feel free to provide any feedback (either by filing bugs or contacting me directly).
New Features:
[...]
Thanks a ton for all the improvements in the EWS! Since we moved the GTK/EWS builders to the new queues they have been faster and more reliable. After solving a couple of minor hiccups right after the switch, the builders have not needed any manual intervention since (with the old system we would need to clean stray files from old builds now and then, but not anymore!)
Glad to hear. New EWS has been more reliable and easier to maintain at our end as well.
\o/
Only remaining queues on old EWS are windows, jsc and commit-queue, which I will be working on next.
Today Xan López and I talked a bit about the JSCOnly queue. We have a many builders targeting different architectures, which we would like to have moved to the new system.
In the case of the JSC port, instead of grouping all of the builders under a single “jsc” status bubble it would be better to have a bubble for each target architecture e.g. “jsc-armv7”, “jsc-arm64”, and so on.
Yes, my plan is to have separate bubbles for different architectures. I will touch base with you when I work on those queues.
The motivation is that we think it makes sense to that the system considers that a patch cannot be landed if it breaks any of the supported JSC architectures. With a single status bubble grouping them, we can have situations where a builder for one architecture passes the build+checks but the patch may still break *some other* architecture (e.g. a patch that touches ARM code generation gets picked by a MIPS builder).
Is the above something that can supported? Let us know if you need more information and/or some support from our side for this.
Best regards, —Adrián