Hi Jörg, Regarding > 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).
That does not differ from the current status quo. Even right now commits are allowed not referencing a JIRA ticket. So there are ways to bypass it (which is IMHO a feature not a but) but for most of the cases people already use a PR (particularly for external contributors this is the only way to contribute). So I am +1 on this proposal. Konrad > On 5. Oct 2026, at 11:12, Jörg Hoh via dev <[email protected]> wrote: > > +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
