[SYCL] Add guidelines for working on release branches #17042
Conversation
|
@intel/llvm-gatekeepers, tagging you explicitly for review, because suggested changes are about our general processes |
| ### Only cherry-picks are allowed | ||
|
|
||
| It is assumed, that everything you do on a release branch, should also be | ||
| repeated on the main branch to ensure that it is automatically included into |
There was a problem hiding this comment.
Perhaps this should be the default branch instead of the main branch to avoid confusion with the upstream main branch which exists but is not the default?
There was a problem hiding this comment.
Addressed this in d3a51ea
| @@ -1,3 +1,21 @@ | |||
| # Release notes for an upcoming release (dates TBD) | |||
There was a problem hiding this comment.
should we also mention a link to tag/branch? sycl-rel-***
There was a problem hiding this comment.
We don't have that branch yet and in general case, we may not even know the next version in advance (i.e. whether it will be X.Y+1 or X+1.0)
|
|
||
| A change should **not** be noted there when: | ||
|
|
||
| - It has no functional and performance impact |
There was a problem hiding this comment.
Maybe also add here any direct changes in our dependencies? Like UR, etc
There was a problem hiding this comment.
If UR change fixes a bug observable on a SYCL level, I would personally prefer it documented
| consistency it is better to follow the existing structure without disrupting it | ||
| much. The structure we have been using so far is split by change type (i.e. new | ||
| features and bug fixes) and then sub-split by component (i.e. compiler, | ||
| runtime). Please use past tense when describing your change. |
There was a problem hiding this comment.
Maybe add that links must be permalinks to avoid dead links in the future?
There was a problem hiding this comment.
Yeah, good point, clarified that in ee3ecc7
| Those branches are intended to indicate stable snapshots of our product so that | ||
| our users don't need to guess which nightly build is good enough for our needs. |
There was a problem hiding this comment.
Optionally:
| Those branches are intended to indicate stable snapshots of our product so that | |
| our users don't need to guess which nightly build is good enough for our needs. | |
| Those branches are intended to indicate stable snapshots of SYCL compiler | |
| in comparison with non-stable nightly snapshots. |
| release branch and then apply it to the main `sycl` branch. The flow goes in | ||
| the opposite direction where you first land a patch to the main branch and then | ||
| backport it to a release branch. | ||
|
|
There was a problem hiding this comment.
Should we add somewhere that if some failure is observed in pre-commit, author of PR should create an issue with specific tag indicating the release (if adding GH tag is not possible due to permissions, issue caption must have a tag in text format like [REL-***]
There was a problem hiding this comment.
I suppose that rules about creating issues for release branches (and any special markup for them) should probably be documented elsewhere in a generic manner (i.e. even for those who do not contribute to release branches, but uses them). But I don't know what this place would be.
Specifically for pre-commit issues observed at release branches, I would prefer to have stricter rules, i.e. it seems wrong to merge a PR with a new failure in a pre-commit into release branch
|
I'm going to proceed with the merge to have some baseline ready. Any further feedback can be applied post-commit (and I still have a TODO item in my list to address @dm-vodopyanov's comment about submitting issues against release branches) |
No description provided.