+1 in general but we need figure the necessary details and have automation for it.
In my opinion we cannot use PRs for release notes, if on the other hand side we don't mandate PRs. for that pushing changes directly to the main branch should be discouraged (disallowing push to main does not work because of the maven release plugin). Jörg Am Do., 1. Okt. 2026 um 16:43 Uhr schrieb Carsten Ziegeler < [email protected]>: > At the Sling community roundtable I brought up the topic of cleaning up > our jira components (a thread I started before here) and this quickly > turned into a discussion on switching to github issues instead (which > would solve my concern as well). Reference notest at [1]. > > Other projects like Apache Maven have moved from Jira to GH issues as > well. So we could do the same. > > The immediate benefit is that the issues are close to code. > > While enabling GH issues is easy, it comes with some questions. The goal > here is to introduce this change with minimal effort, increasing the > burden to contribute must be avoided. > > a) Migration of issues from Jira? > > Do we need / want to migrate open or even all issues from jira to GH. > There is most likely no real benefit of doing so. Most open issues are > open for a long time and there are only a few which are really worked > on. So a on demand migration or copying over seems to be more appropriate. > > Instead, we can lock down Jira to prevent new issues to be created, but > still allowing to comment on existing issues. (Actually, we are > currently using a default permission scheme in Jira that does not allow > this, but we can ask Infra if that can be switched) > That way, we don't have to migrate tons of issues from the last decades, > a lot of them probably outdated or not easily matchable. > > b) Release Notes > > Right now, the release notes are based on jira issues. While we could do > the same with GH issues, the better approach is to base this on PRs > merged into it since the laste release. GH provides this out of the box. > > c) Require PRs > > With basing the release notes on PRs, the question is whether we require > a PR for every change? This does not seem necessary and simple changes > do not need to clutter the release notes. This is no change to what we > do today with Jira issues. > > d) Require Issues > > Similar, we will not enforce an GitHub issue to be created for every PR > - if the PR is simple and self-contained > > e) Issues spanning multiple repos > > If there is an issue that spans multiple repos, you have to create > multiple issues and link them. This is actually a cleaner way, > especially as releases of these modules are independently done. > > Thoughts? > > Regards > Carsten > > [1] > > https://cwiki.apache.org/confluence/spaces/SLING/pages/451979035/Committer+round+table+at+adaptTo+2026 > -- > Carsten Ziegeler > Adobe > [email protected] > > -- https://cqdump.joerghoh.de
