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ł
--
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.
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?
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.
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.
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.
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.