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.
Includes the following updates:
- Spacing and capitalization fixes for readability
- Corrects instructions on updating AVD dependencies
- Links to engine docs to reduce redundancy
**TLDR:** Move the changelog, currently called ["hotfixes to the stable
channel"](https://github.com/flutter/flutter/blob/master/docs/releases/Hotfixes-to-the-Stable-Channel.md),
to the root directory of Flutter/Flutter and rename it to CHANGELOG.md
before the Q3 release cutoff.
This PR accomplishes the following:
1. Renames 'Hotfixes-to-the-stable-channel' to CHANGELOG.md
2. Moves CHANGELOG.md to Flutter/Flutter root.
3. Update references to 'Hotfixes-to-the-stable-channel' to
CHANGELOG.md.
---
#### Background
Flutter has historically kept documentation on wiki pages in the Flutter
repository. Recently, we executed a large-scale migration of our wiki
into a `docs` folder within flutter/flutter.
#### Proposal
I propose relocating the current changelog, which is called ["hotfixes
to the stable
channel"](https://github.com/flutter/flutter/blob/master/docs/releases/Hotfixes-to-the-Stable-Channel.md),
to the root directory of the Flutter/Flutter repository and renaming it
to CHANGELOG.md. This change aims to improve the visibility,
accessibility, and consistency of our documentation processes.
#### Benefits
1. **Unify Dart and Flutter Processes:** This move aligns Flutter’s
changelog management with Dart's practices. As the release manager for
both Dart and Flutter, this unification will streamline the processes
and ensure consistency across projects.
#### Timeline
I would like this proposal **approved or denied before the Q3 release
cutoff** so it may be available within the stable branch.
---
> [!NOTE]
> This proposal aims to improve our workflow and documentation
standards. I am open to feedback and further discussion on how we can
best implement this change.
Make it more clear that every design doc has a corresponding github tracking issue with appropriate label.
*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].*
Update style guide to include anti pattern of mentioning someone in a comment and the flurry of notifications that result.
Came up in a google contributor roundtable discussion.
We are pausing our cadence of removing deprecated API from the framework until we can create a new policy.
The last couple of cycles we noticed customers having more difficult migrations, and it being harder to remove the APIs in the scheduled time period. So we need to reevaluate the policy and update it.
This is the policy working as intended. Signals like flutter/tests provide feedback on how we are affecting users - so that for folks that contributed!
Related to https://github.com/flutter/website/pull/10839
