[Decoupling] Port over open PRs from flutter/flutter to material_ui or cupertino_ui #188444

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?

• Any open PRs with the override-code-freeze label: https://github.com/flutter/flutter/pulls?q=is%3Apr+label%3A%22override+code+freeze%22+is%3Aopen
• Open PRs with the waiting-on-code-freeze label: https://github.com/flutter/flutter/pulls?q=is%3Apr+is%3Aopen+label%3A%22waiting+for+code+freeze%22+
• Any other open PRs that might not have the label but that do affect the directories copied in Decoupling recopy packages#11888. How to best detect these? The directories that were copied are:
  • packages/flutter/lib/src/material
  • packages/flutter/test/material
  • examples/api/lib/material
  • examples/api/test/material
  • packages/flutter/lib/src/cupertino
  • packages/flutter/test/cupertino
  • examples/api/lib/cupertino
  • examples/api/test/cupertino
  • packages/flutter/lib/fix_data/fix_material
  • packages/flutter/test_fixes/material
  • packages/flutter/lib/fix_data/fix_cupertino.yaml
  • packages/flutter/test_fixes/cupertino

How should PRs be ported?

If possible, the easiest way may be to cherry pick the commits to flutter/packages:

1. Take note of the flutter/flutter PR number that you are porting over. This will be referenced as <PR#> in the steps below.
2. Cherry pick the commits from the PR into a new branch in flutter/packages. Do not include merge commits.

• a. Fetch the flutter/flutter master branch.

git fetch https://github.com/flutter/flutter.git refs/heads/master:refs/flutter-master

• b. Fetch the flutter/flutter PR to port.

git fetch https://github.com/flutter/flutter.git pull/<PR#>/head:refs/pr-<PR#>

• c. List out all the commits in the PR. Confirm they match what you see on Github, and that there are no merge commits.

git rev-list --no-merges --reverse refs/flutter-master..refs/pr-<PR#>

• d. If the commit list looks correct, then cherry-pick them.

git cherry-pick $(git rev-list --no-merges --reverse refs/flutter-master..refs/pr-<PR#>)

3. Fix any conflicts and ensure that the changes ended up in the correct directories.
4. Add a changelog entry. See the note about changelog entries below.
5. Push your branch and open a new PR. Tag the original author.
6. Close the old PR and leave a comment pointing to the new PR.
7. Clean up your fetched git references:

git update-ref -d refs/flutter-master
git update-ref -d refs/pr-<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.

The flutter/packages changelog file

There is one key difference to know when submitting a PR in flutter/packages: you'll need to create a pending change file that includes your changelog entry and version bump.

You can make a copy of the template.yaml file for material_ui or for cupertino_ui and fill out the details.

Alternatively, you can use the Flutter Packages Tool. Follow the configuration instructions and then from either the material_ui or cupertino_ui directory, run:

fpt update-release-info --current-package --version <next,bugfix,minor> --changelog "<Change description>"

PRs that make changes in Material/Cupertino along with other changes

If the PR makes additional changes outside of Material or Cupertino, it will need to be split up. This also may mean that the changes in material_ui and cupertino_ui need to wait for the changes in Flutter's core SDK to reach the stable channel.

For example:
If the PR makes changes in the Material library and the Widgets library, they will need to be split up.
The Widgets changes will land in flutter/flutter, while the Material changes will land in material_ui in flutter/packages.
If the Material changes are dependent on the changes in Widgets, then the Material changes will have to wait for the Widgets changes to reach Flutter's stable branch.

Not sure?

Ping @Piinks if you need help. We're happy to help everyone through the transition.

Related

Similar to #188441, which covers porting over merged PRs.