PSA: redundant bots removed from chromium.webkit

129 views
Skip to first unread message

Paweł Hajdan, Jr.

unread,
Aug 17, 2015, 10:07:58 AM8/17/15
to blink-dev, infr...@chromium.org
I've just landed a change which removes several bots from chromium.webkit, now that we're running chromium CQ builders on blink CQ and blink auto roll bot uses NOTRY=true: https://codereview.chromium.org/1300623002 .

Enjoy cleaner chromium.webkit!

Next steps would include removing the blink scheduler from chromium.webkit, i.e. only testing chromium changes (which will include blink rolls landed with NOTRY=true). To hopefully better explain what would happen, I'm attaching a diagram - we'd continue testing the changes with git shas, but not svn revision numbers:




And as a next step after that, chromium.webkit would get added to http://build.chromium.org !

Please let me know if you have any questions or concerns.

Paweł

Dirk Pranke

unread,
Aug 17, 2015, 1:08:00 PM8/17/15
to Paweł Hajdan, Jr., blink-dev, infr...@chromium.org
On Mon, Aug 17, 2015 at 7:07 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:
I've just landed a change which removes several bots from chromium.webkit, now that we're running chromium CQ builders on blink CQ and blink auto roll bot uses NOTRY=true: https://codereview.chromium.org/1300623002 .

Enjoy cleaner chromium.webkit!

Next steps would include removing the blink scheduler from chromium.webkit, i.e. only testing chromium changes (which will include blink rolls landed with NOTRY=true).

If I'm understanding this correctly, this means that we will have no continuous tests running on 'upstream' commits, and we will only have coverage on changes once they've rolled into chromium. Is that correct?

-- Dirk
 
To hopefully better explain what would happen, I'm attaching a diagram - we'd continue testing the changes with git shas, but not svn revision numbers:




And as a next step after that, chromium.webkit would get added to http://build.chromium.org !

Please let me know if you have any questions or concerns.

Paweł

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAATLsPb2%3Dy6cSdDJsaRct1iP0wfyBOxv7BVKSkYOcGR4m8eHKg%40mail.gmail.com.

Paweł Hajdan, Jr.

unread,
Aug 17, 2015, 2:16:22 PM8/17/15
to Dirk Pranke, blink-dev, infr...@chromium.org
On Mon, Aug 17, 2015 at 7:07 PM, Dirk Pranke <dpr...@chromium.org> wrote:
If I'm understanding this correctly, this means that we will have no continuous tests running on 'upstream' commits, and we will only have coverage on changes once they've rolled into chromium. Is that correct?

Yes. There is some risk related to that. I think it's a reasonable tradeoff though. Let me know if you'd prefer to keep the 'upstream' coverage - the change has not been made yet and it's important for me to achieve consensus about it.

Note that without removing the blink scheduler it'd probably be hard to add chromium.webkit to build.chromium.org. We could still do that after the merge, I'm just trying to complete as many steps as possible before it (so we can ensure they're well tested).

Paweł

Dirk Pranke

unread,
Aug 17, 2015, 2:45:27 PM8/17/15
to Paweł Hajdan, Jr., blink-dev, infr...@chromium.org
On Mon, Aug 17, 2015 at 11:15 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:
On Mon, Aug 17, 2015 at 7:07 PM, Dirk Pranke <dpr...@chromium.org> wrote:
If I'm understanding this correctly, this means that we will have no continuous tests running on 'upstream' commits, and we will only have coverage on changes once they've rolled into chromium. Is that correct?

Yes. There is some risk related to that. I think it's a reasonable tradeoff though. Let me know if you'd prefer to keep the 'upstream' coverage - the change has not been made yet and it's important for me to achieve consensus about it.

I don't know if we've been running the NOTRY roll long enough to get much data on failures; we'd want to see if any chromium sheriffs 
(or blink gardeners) have had any issues w/ reverting changes that caused failures downstream.

What's the latest thinking on when we'd do the actual merge?

Also, I'm not working on Blink much at the moment, so you'd probably want actual Blink devs to weigh in if they have any complaints.
If not, I think silence == consent in this case, and we can always reverse things if need be.

-- Dirk

Paweł Hajdan, Jr.

unread,
Aug 18, 2015, 5:38:34 AM8/18/15
to Dirk Pranke, blink-dev, infr...@chromium.org
On Mon, Aug 17, 2015 at 8:44 PM, Dirk Pranke <dpr...@chromium.org> wrote:
On Mon, Aug 17, 2015 at 11:15 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:
On Mon, Aug 17, 2015 at 7:07 PM, Dirk Pranke <dpr...@chromium.org> wrote:
If I'm understanding this correctly, this means that we will have no continuous tests running on 'upstream' commits, and we will only have coverage on changes once they've rolled into chromium. Is that correct?

Yes. There is some risk related to that. I think it's a reasonable tradeoff though. Let me know if you'd prefer to keep the 'upstream' coverage - the change has not been made yet and it's important for me to achieve consensus about it.

I don't know if we've been running the NOTRY roll long enough to get much data on failures; we'd want to see if any chromium sheriffs 
(or blink gardeners) have had any issues w/ reverting changes that caused failures downstream.

Good point. Sure, this can wait a bit more. Now I'm glad I included the "next steps" in my message.
 
What's the latest thinking on when we'd do the actual merge?

In September, when Jochen is back from vacation.
 
Also, I'm not working on Blink much at the moment, so you'd probably want actual Blink devs to weigh in if they have any complaints.
If not, I think silence == consent in this case, and we can always reverse things if need be.

Yup, we can go back - and if we have to (unlikely), I'd rather do that sooner than later, i.e. before the merge.

Please speak up if anything seems to be going in an unhappy direction. We're taking these steps now when they're still relatively easy to revert.

Paweł

Paweł Hajdan, Jr.

unread,
Sep 2, 2015, 10:14:14 AM9/2/15
to Dirk Pranke, blink-dev, infr...@chromium.org
On Tue, Aug 18, 2015 at 11:38 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:
On Mon, Aug 17, 2015 at 8:44 PM, Dirk Pranke <dpr...@chromium.org> wrote:
On Mon, Aug 17, 2015 at 11:15 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:
On Mon, Aug 17, 2015 at 7:07 PM, Dirk Pranke <dpr...@chromium.org> wrote:
If I'm understanding this correctly, this means that we will have no continuous tests running on 'upstream' commits, and we will only have coverage on changes once they've rolled into chromium. Is that correct?

Yes. There is some risk related to that. I think it's a reasonable tradeoff though. Let me know if you'd prefer to keep the 'upstream' coverage - the change has not been made yet and it's important for me to achieve consensus about it.

I don't know if we've been running the NOTRY roll long enough to get much data on failures; we'd want to see if any chromium sheriffs 
(or blink gardeners) have had any issues w/ reverting changes that caused failures downstream.

Good point. Sure, this can wait a bit more. Now I'm glad I included the "next steps" in my message.

Checking back: are there any concerns about removing the blink scheduler from chromium.webkit, which will result in only testing the chromium commits? Note the blink auto-roller uses NOTRY=true, so each blink CL should make it very quickly to the chromium tree.

Paweł

Ojan Vafai

unread,
Sep 3, 2015, 4:21:33 AM9/3/15
to Paweł Hajdan, Jr., Dirk Pranke, blink-dev, infr...@chromium.org

I think that would be a good change, but thinking about it more, we should merge the tree status first. If the chromium tree is closed, the blink tree should be too. That way we won't get large regression ranges if the chromium tree is closed for a long time.

To be clear, I'm proposing we get rid of blink-status.appspot.com and have the blink presubmit use chromium-status before making this change.

Dirk Pranke

unread,
Sep 3, 2015, 11:43:35 AM9/3/15
to Ojan Vafai, Paweł Hajdan, Jr., blink-dev, infr...@chromium.org
I agree with both of these suggestions (close blink when chromium is closed, and then remove the blink scheduler).

-- Dirk
Reply all
Reply to author
Forward
0 new messages