Since Material and Cupertino are frozen in flutter/flutter, and their main code has been copied to flutter/packages in flutter/packages#11888, we should port to flutter/packages any open PR that affects the ported code.
Which PRs should be ported?
How should PRs be ported?
If possible, the easiest way may be to cherry pick the commits to flutter/packages:
- Cherry pick the commits from the PR into a new branch in flutter/packages. Do not include merge commits.
git remote add <author's GitHub ID> git@github.com:<author's GitHub ID>/flutter.git
git fetch <author's GitHub ID>
git cherry-pick <list of SHAs from the author's PR, excluding merge commits>
- Fix any conflicts and ensure that the changes ended up in the correct directories.
- Push your branch and open a new PR. Tag the original author.
- Close the old PR and leave a coment pointing to the new PR.
Some of the affected tests may be in the temporarily_disabled_tests directory of cupertino_ui or material_ui. If your change is fixing a gross import for these tests, they may be moved to the main test directory.
For an example PR, see flutter/packages#11965.
Related
Similar to #188441, which covers porting over merged PRs.
Since Material and Cupertino are frozen in flutter/flutter, and their main code has been copied to flutter/packages in flutter/packages#11888, we should port to flutter/packages any open PR that affects the ported code.
Which PRs should be ported?
How should PRs be ported?
If possible, the easiest way may be to cherry pick the commits to flutter/packages:
Some of the affected tests may be in the
temporarily_disabled_testsdirectory of cupertino_ui or material_ui. If your change is fixing a gross import for these tests, they may be moved to the main test directory.For an example PR, see flutter/packages#11965.
Related
Similar to #188441, which covers porting over merged PRs.