Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compare branch contents without immediate merge #284

Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/ISSUE_TEMPLATE/1-lts-release-checklist.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is happening on release day you can't email the developer mailing this about this at this point

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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/*)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


- [ ] Assure that contents of master branch have been merged to the stable branch in the [packaging repository](https://github.com/jenkinsci/packaging), e.g. `stable-2.277`
- [ ] Compare the contents of the [packaging repository](https://github.com/jenkinsci/packaging) 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

- [ ] Announce the start of the LTS release process in the #jenkins-release and #jenkins-infra IRC channels

Expand Down