docs: Add guidelines for handling serial PR dependencies#98391
docs: Add guidelines for handling serial PR dependencies#98391JarmouniA wants to merge 1 commit into
Conversation
61d4777 to
9041daa
Compare
|
|
||
| - Propagate Changes | ||
|
|
||
| Any updates to PR A must be manually propagated to PR B, and then from PR B to PR C. |
There was a problem hiding this comment.
Mention that propagation must happen after the PR is merged.
There was a problem hiding this comment.
Do you mean PR B is rebased on main after A is merged?
Clarify the process for managing and reviewing pull requests with serial dependencies. This helps contributors understand how to structure, propagate changes, and validate dependent PRs effectively. Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
9041daa to
68e157c
Compare
|
|
Not sure how I feel about this to be totally honest, github makes it so hard I feel like the guideline should be "don't do it" |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
I am not sure this how things are done today. It feels odd to document that people should open draft PRs when in fact I believe they should be open-open (with a clear indication of which commit(s) may be reviewed) but simply marked as DNM. |
The problem with that is when what's being contributed is touching many areas, it results in a ton of unrelated reviewers & labels being added to the subsequent PRs, so no one knows what PR to review really. |
|
This pull request has been marked as stale because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 7 days. Note, that you can always re-open a closed pull request at any time. |



Clarify the process for managing and reviewing pull requests with serial dependencies. This helps contributors understand how to structure, propagate changes, and validate dependent PRs effectively.
Originated from #90216 (comment)
Doc preview https://builds.zephyrproject.io/zephyr/pr/98391/docs/contribute/contributor_expectations.html#contributor-expectations