1_All texts in italics are instructional and should be replaced by contents or removed._ 2 3## Checklist 4 5_This entire section can be deleted if all items are checked._ 6 7* [ ] Enough information to help reviewers understand the issue, its root cause, impact, and the proposed solution 8* [ ] Enough information to help reviewers understand the feature, its functional description, example, documentation, test cases, test results, feature TODO list 9* [ ] The MR Title describes the change, including the component name, ie "lwip: Add support for IP over Pigeon" 10* [ ] All related links, including JIRA, backport, submodule MR, are mentioned in the `Related` subsection. 11* [ ] Any GitHub issues are linked inside the git commit message and corresponding release notes 12* [ ] Add label for the area this MR is part of 13* [ ] For documentation updates, check if label `Docs` and `needs translation:CN` or `needs translation:EN` have been added when the other language version still needs the update. Skip adding the label if the document is not yet translated. 14* [ ] Check if documents requiring translation fall under get-started section. If yes, add the labels mentioned above. Then the documentation team will assign a translator for you. Please inform the translator to prepare translation once your MR is ready to merge. The translation should be included in your MR to get it merged. For more information, see documentation workflow in Wiki. 15* [ ] Any necessary "needs backport" labels are added 16* [ ] Check if this is a breaking change. If it is, add notes to the `Breaking change notes` subsection below 17* [ ] Release note entry if this is a new public feature, or a fix for an issue introduced in the previous release. 18* [ ] The commit log is clean and ready to merge. 19* [ ] All relevant CI jobs have been run, i.e. jobs which cover the code changed by the MR. 20* [ ] Pipeline with Python 3 has been successfully run, i.e. `@bot ...; with Python3`, if the MR adds or changes Python code. 21 22--- 23 24_For issues, put enough information here to help reviewers understand the issue, its root cause, impact, and the proposed solution._ 25 26_If this issue is a regression, specify in the `Related` subsection below, in which commit or MR it was introduced. This helps reviewers to check if the backport labels are set correctly._ 27 28--- 29 30_For features, put enough information here to help reviewers understand the feature, its functional description, example, documentation, test cases, test results, feature TODO list._ 31 32--- 33 34_For other small/non-public changes, which are not expected to be in the release notes, can be mentioned here, include:_ 35 36 * changes that don't apply to customers, e.g. some CI fixes, test only MR and etc 37 38## Related 39 40* Mention or related JIRA tasks (e.g. IDF-0000), to make sure they get updated. 41* Mention submodule MR, if there is 42* Mention backport(ed) MR, if there is 43 44_Don't touch the subsection titles below, they will be parsed by scripts._ 45 46## Release notes (Mandatory) 47 48_Changes made in this MR that should go into the **Release Notes** should be listed here. Please use **past tense** and *specify the area (see maintainers page of IDF internal wiki)*. If there is a subscope, include it and separate with slash (`/`). Minor changes can go to the descriptions above without a release notes entry._ 49 50_Write all the changes in a **list** (Start at the beginning of the line with `-` or `*`). If multiple changes are made, each of them should take a single line. If there is only one change to list, it should still be the only line of a list. If this MR does not need any release notes, write "No release notes" here without the `-` or `*`. e.g._ 51 52* [WiFi] Changed/fixed/updated xxx 53* [WiFi] Added support of xxx 54* [Peripheral Drivers/I2S] Fixed xxx (https://github.com/espressif/esp-idf/issues/xxxx) 55 56## Breaking change notes 57 58_Remove this subsection if not used._ 59 60_If there are any breaking changes, please mention it here. Talking about (1) what is not accepted any more, (2) the alternative solution and (3) the benefits/reason. e.g._ 61 62_Please strictly follow the breaking change restriction, which means, if there is a breaking change but you are merging to non-major versions, you have to separate the breaking part out to another MR for a major version. The breaking change subsection is only accepted in MRs merging to major versions._ 63 64* [VFS/UART] Now vfs_uart_set_rts_cts accept one more instance argument, to support configuration to different ports. 65
