From 42c697cfb6a09dfce2cd56a223d9186fa2936837 Mon Sep 17 00:00:00 2001 From: Justin McCandless Date: Tue, 12 Aug 2025 15:53:27 -0700 Subject: [PATCH 1/2] Improve 'if a test is broken' --- README.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 577a4265..0dcc26c6 100644 --- a/README.md +++ b/README.md @@ -91,7 +91,7 @@ Use `./scripts/verify_tests_on_main.sh --help` to see more options. The point of these tests is to make sure we don't break existing code, while still being able to make improvements to Flutter APIs. -If you find that a PR you have created in flutter/flutter causes one +If you find that a PR you have created in flutter/flutter causes one of these tests to fail, you have the following options: 1. Change your PR so that the test no longer fails. This is the @@ -100,7 +100,7 @@ these tests to fail, you have the following options: with without the backwards-compatibility constraint? That's good. Is the resulting API something that, as soon as you see it, you think "why?" or "that's weird"? That's bad. Consider the advice in - the Style guide: + the style guide: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md 2. Go through the breaking change process, as documented here: @@ -110,13 +110,16 @@ these tests to fail, you have the following options: files), help them fix their code, and update this repository to use the new version of their tests, in addition to the steps described on the wiki. You will also need to land your change in two parts, - so that people have time to migrate (a "soft-breaking" change). + so that people have time to migrate (a "soft-breaking" change). See Flutter's + [deprecation policy](https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#deprecations) + for more. 3. Remove the test in question. This is by far the least ideal solution. To go down this path, we must first establish that one of the following is true: - - the people listed as contacts for the test are not responsive (within 72 hours). + - the people listed as contacts for the test are not responsive and a plan + to fix the failure has not been agreed upon within 72 hours. - the test is poorly written (e.g. it contains a race condition or relies on assumptions that violate clearly documented API From 59865014ddbd4f40d5377facc15ebfc318a80789 Mon Sep 17 00:00:00 2001 From: Justin McCandless Date: Tue, 21 Oct 2025 08:59:57 -0700 Subject: [PATCH 2/2] Review --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0dcc26c6..116fb428 100644 --- a/README.md +++ b/README.md @@ -112,7 +112,7 @@ these tests to fail, you have the following options: on the wiki. You will also need to land your change in two parts, so that people have time to migrate (a "soft-breaking" change). See Flutter's [deprecation policy](https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#deprecations) - for more. + for more details. 3. Remove the test in question. This is by far the least ideal solution. To go down this path, we must first establish that one of