You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/reference/contributing/guidelines/workflow.md
+11-1Lines changed: 11 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -167,20 +167,30 @@ All pull requests must be reviewed. The Arm Mbed CI bot determines the most suit
167
167
168
168
Github dismisses a reviewer's status after any change to the pull request commit history (such as adding a new commit or rebasing). Smaller changes, such as documentation edits or rebases on top of latest master, only require additional review by maintainers. Their approval is sufficient because a team assigned as a reviewer already approved the pull request.
169
169
170
+
Label: `needs: CI`
170
171
Time: 3 days for reviewers to leave feedback after the maintainers add the "needs: review" label.
171
172
172
173
#### The CI (Continuous Integration) testing
173
174
174
175
There are many CI systems available. Which CI tests we run against a particular pull request depends on the effect that pull request has on the code base. Irrespective of which CI tests run, Mbed OS has an all green policy, meaning that all the CI jobs that are triggered must pass before we merge the pull request.
175
176
177
+
Label: `needs: review`
176
178
Time: 1 day for CI to complete and report back results.
177
179
178
180
#### Work needed
179
181
180
182
A pull request in the work needed state requires additional work due to failed tests, or rework as a result of the review. If a pull request is in this state, then our maintainers request changes from the pull request author.
181
183
184
+
Label: `needs: work`
182
185
Time: 3 days for the pull request author to action the review comments.
183
186
187
+
#### Ready for integration
188
+
189
+
Maintainers merge pull requests during the internal gatekeeping meetings that occur three times a week. They can merge straightforward pull requests immediately.
190
+
191
+
Label: `Ready for merge`
192
+
Time: 2 days
193
+
184
194
#### Releases
185
195
186
196
When we merge a pull request that we will publish in a patch release, we tag the pull request with the specific patch release version. This is the release in which we first publish this pull request. For patch releases, we allow only bug fixes, new targets and enhancements to existing functionality. New features only go in feature releases.
@@ -196,7 +206,7 @@ We use many other labels to summarize the scope and effect of the changes.
196
206
-*needs: preceding PR* - This pull request cannot yet be merged because it has a dependency on another pull request that needs to merge first.
197
207
-*DO NOT MERGE* - This pull request contains changes that may be in a draft state and submitted purely for review, or may contain breaking changes that have not been considered.
198
208
-*devices: 'name'* - The pull request specifically affects the named device(s).
199
-
-*component: 'name'* - The pull request specifically affects the named component.
209
+
-*component: 'name'* - The pull request specifically affects the named component. Component names follow the structure of Mbed OS (`ble`, `storage`, `tls` and so on).
200
210
201
211
The following labels summarize the scope of the pull request.
0 commit comments