Compare branch contents without immediate merge #284
Conversation
Correct the checklist phrasing to note that we need to review changes from the master branch but we don't want to merge them without discussion and consideration of the impact of each of the differences. jenkinsci/packaging#332 (comment) is the inspiration for this pull request.
| @@ -66,9 +66,9 @@ This role should rotate between LTS releases | |||
|
|
|||
| - [ ] Publish changelog (one day prior to the release in case of a security update) | |||
|
|
|||
| - [ ] Assure that contents of master branch have been merged to the stable branch in the [release repository](https://github.com/jenkins-infra/release), e.g. `stable-2.277` | |||
| - [ ] Compare the contents of the [release repository](https://github.com/jenkins-infra/release) master branch with the stable branch (e.g. `stable-2.361`). Discuss differences in the Jenkins developers mailing list in case one or more of those differences should be backported | |||
There was a problem hiding this comment.
This is happening on release day you can't email the developer mailing this about this at this point
There was a problem hiding this comment.
Do we need a new heading that is "a day or two before release"? This would move to that section so that there is time to discuss it before the release.
There was a problem hiding this comment.
I don’t think it’s worth it, these branches don’t differ much and generally it’s easier to keep them as close as possible. The times we want to keep them different is incredible rare.
but failing a release because some infra change wasn’t backported is more often
There was a problem hiding this comment.
Would it make sense to get a rid of both points? Do we actually need the content on the master branch on a stable branch outside the backporting process?
There was a problem hiding this comment.
@NotMyFault yes some changes must be backported from the principal branch to the stable branch at least on the infrastructure point of view for the pipelines (Jenkinsfile.d/*), the pod templates associated to these pipelines (PodTemplates.d/*)
There was a problem hiding this comment.
I've opened this issue a few months ago: #250 about this topic.
TL;DR; as much as the "stable branches" model fits the core, the packaging and the core Docker image, it's harder to justify here and a "only a main branch" pattern is proposed.
Compare branch contents without immediate merge
Correct the checklist phrasing to note that we need to review changes from the master branch but we don't want to merge them without discussion and consideration of the impact of each of the differences.
jenkinsci/packaging#332 (comment) is the inspiration for this pull request.