Came up in triage, no bug.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
🚫 **BLOCKED** : Do not merge until
https://github.com/flutter/flutter/issues/161261 (additional test
coverage).
---
This PR eliminates (1) `scenario_app/android`, and all references to an
Android `scenario_app`, including documentation, CI configuration, build
rules, test runner, Android-side test application, and (2), to verify
and disambiguate the remains, renames the folder `ios_scenario_app`,
which is now accurate.
It also eliminates elements that were _only_ used in the Android-side
scenario_app, such as Firebase Test Lab uploading.
I would be open to doing this in phases if we thought it was better to
do so, but given its mostly a mechanical change (and by renaming the
directory, references can be checked merely by looking for
`/\bscenario_app/`, I believe this is safe to iterate on and eventually
merge after the holidays.
## Background
As of the merged mono-repo, there is no longer a requirement for the
engine to be testable as a standalone unit.
As an example,
[`%ENGINE%/testing/scenario_app`](3762f2e973/engine/src/flutter/testing/scenario_app),
which was intended to _emulate_ the Flutter framework (and some of
`flutter_tools` tooling), load the iOS and Android embedder, and run
various "scenarios" (which ran a combination of `dart:ui` code and
Android Java/iOS Obj-C) verifying golden-file screenshots.
Instead, it is now possible to write and run _real_ (full) Flutter apps
the same way that an end-user (or our own tests) would. One such example
is
[`dev/native_driver_test`](https://github.com/flutter/flutter/tree/master/dev/integration_tests/native_driver_test),
which is a full-fledged Flutter app, which uses standard tooling (i.e.
`flutter`), to test most of the same elements that previously were only
tested in the Android version of `scenario_app`.
Updates to the Flutter cherry-pick process to align with our current
practices. This update:
1. Defaults to automated cherry-picks.
2. Removes the need to create cherry-pick issues.
3. Requires cherry-pick authors to update CHANGELOG.md.
---------
Co-authored-by: Christopher Fujino <christopherfujino@gmail.com>
No issue
Related to
https://github.com/flutter/packages/pull/7985#issuecomment-2557237025
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
Recently I learned that (at least in `team-framework` and `team-design`
triage meetings) we'd like to see all incoming issues, even ones that
already have an assignee.
This PR removes a filter so that this will happen in the future.
resolves#155700
Correct the Quality-Assurance contributing doc's wrong git command.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] All existing and new tests are passing.
Adds special handling of the newly-imported `flutter_svg` and
`vector_graphics` family of packages in the triage flow chart, as they
should be directed to the engine team.
Follow-up to https://github.com/flutter/flutter/pull/153599. This updates the tool readme, suggesting `bin/flutter-dev` as the primary way to run the flutter tool locally from source.
<details>
<summary> Pre-launch checklist </summary>
</details>
Updates the paths for test files to reflect the `darwin/` structure, and updates the instructions for enabling tests to use the SPM version of OCMock if necessary (as well as flagging that new use of OCMock is discouraged).
In order to have a dedicate chat room for tree issues with a high signal to noise ratio, we've separated out a new `tree-gardener` channel from the `tree-status` channel on Discord. This updates the gardener docs to reference the new human-centric tree-gardener chat.
I've removed the line suggesting that people avoid spamming the room with requests for "when will this be resolved?" and "can I get an update?" since the doc is aimed mostly at the gardener themself and and not likely being read by those on chat asking "when will the tree be fixed?" Recently this hasn't been a source of noise.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
- [] I listed at least one issue that this PR fixes in the description above.
- [] I added new tests to check the change I am making, or this PR is [test-exempt].
- [] I followed the [breaking change policy] and added [Data Driven Fixes] where supported.
- [] All existing and new tests are passing.
## Detail
The correct parameter is --web-port, not --webport
Combine iOS and macOS triage links since it's completed in the same meeting.
1. Remove `no:assignee` from both incoming issue links, as these should still be triaged.
2. Combine P0 issue and packages PR links. Other links are harder to combine. For example, macOS PRs looks for `"affects: desktop"` but iOS PRs do not.
Title and initial timeline addition for flutter android 14 platform view
issues.
Internal to google version of this doc.
[go/flutter-android-14-postmortem](http://goto.google.com/flutter-android-14-postmortem)
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [ ] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
This pull request updates the style guide for improved internal consistency and to match current linter rules.
I'll make comments for each change here!
Noticed the framework triage was doing this, adopting it for design languages as well!
Critical triage follows up on these draft PRs if they sit for long without an update. Having draft PRs allows folks to discuss changes without getting nudged constantly to make progress on it. This feels like a really positive change.
