3 notable places I did not migrate.
1. engine/src/flutter/docs/Engine-disk-footprint.md treemaps and what
hash is used for what upload.
1. engine/src/flutter/lib/gpu/pubspec.yaml, I didnt want this pr to
update code that could need to be reverted and I didnt know what to do
to test that publishing would not break or cause a downstream breakage.
1. engine/src/flutter/build/zip_bundle.gni I wasnt sure how to test my
changes.
Reviewers: Please let me know if you want a different link or if you
would prefer something unmodified.
Commits:
- **Replace triage links with equivalents, change pull request to
generic flutter/flutter, replace code search link with equivalent**
- **Change link from flutter/engine to engine folder, modify link text
to team**
- **replace engine repo link with engine folder, replace text repo with
folder**
- **replace engine specific security info with flutter generic**
- **replace engine roller comment with a skia roller equivalent**
- **link to same file in new location**
- **Remove comment that some code lives in flutter/flutter and some in
flutter/engine**
- **Say to bump dart in flutter/flutter without mentioning engine**
- **Replace documentation with new locations**
- **replace code printed comments with new locations**
Partially addresses https://github.com/flutter/flutter/issues/167478
## 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] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] 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.
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.
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
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.
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.
*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].*
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.
Currently the ecosystem team triages all PRs in the packages repository, but the platform teams also triage all PRs with their platform label. Due to the way PRs in packages work, however, it's relatively common for a PR to not be relevant to all the teams' triages at all times. Common examples:
- One platform team may LGTM a multi-platform PR for their platform's portion, while another platform goes through review for several more weeks.
- A cross-platform PR may not have high-level design approval from the ecosystem owner, at which point platform implementation review is premature.
To avoid PRs showing up repeatedly in a platform team's triage when it's not relevant, this adjusts the triage structure:
- Queries for PRs in platform teams query `triage-<platform name>` rather than `platform-<platform name>`
- Ecosystem triage will add the `triage-<platform name>` label during triage when a PR is ready for that platform team's consideration.
- Platform teams can remove the label when it's not relevant to them (e..g, after it's been LGTM'd for that platform).
This also adds a desktop PR query, since there wasn't one, covering the separate platforms. They are separated to allow for more triage flexibility in the future.
