You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2026/10/01 14:41:51 UTC
[RT] Switch to github issues
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
cziegeler@apache.org
Re: [RT] Switch to github issues
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2026-10-01 at 16:41 +0200, Carsten Ziegeler wrote:
> Thoughts?
+1.
The only mention that I have with regards to release notes is that we
will need to be careful when releasing a project for the first time
after the migration to GitHub because some of the changes might only be
reflected in JIRA and not in pull requests.
Thanks,
Robert
Re: [RT] Switch to github issues
Posted by Carsten Ziegeler <cz...@apache.org>.
We most likely will get nicer release notes if we use PRs as the base.
Apart from that, requiring PRs does not solve anything - it is easy to
create a PR and merge instead of directly pushing to main. This would
only change if we enforce checks/approvals for PRs as well...and that is
something we really should not get into at this point.
So, it seems we all agree, I guess a formal vote is next.
Regards
Carsten
On 10/6/2026 9:32 AM, Stefan Seifert via dev wrote:
> i also vote for creating release notes based on PRs - this should cover all relevant changes and is most helpful for the users.
>
> at the same time, I also agree that committing directly the master branch should be done as rarely as possible and only for really cosmetic stuff - e.g. fixing a typo in a javadoc comment - and not for anything relevant, esp. not for actual changes in the (non-test) code. dependency updates (driven by renovate or manually), parent POM updates etc. should be done with a PR.
>
> if we apply labels to PRs (e.g. a label for dependency updates, bug, features), we can create nicely grouped changelogs based on the PRs.
>
> stefan
>
>
>> -----Original Message-----
>> From: Konrad Windszus <kw...@apache.org>
>> Sent: Monday, October 5, 2026 8:01 PM
>> To: dev@sling.apache.org
>> Cc: Jörg Hoh <jh...@googlemail.com>
>> Subject: Re: [RT] Switch to github issues
>>
>> Hi Jörg,
>> Deriving release notes from commits only lack important classification
>> from labels given to PRs.
>> Also commit message are usually a bit more technical and also verbose than
>> what you want to appear in release notes.
>> Also some features/bugfixes are comprised of multiple commits.
>>
>> I would suggest to start trying it out like Maven does. Look at
>> https://github.com/apache/maven-gh-actions-
>> shared/blob/v5/.github/workflows/release-drafter.yml and
>> https://github.com/release-drafter/release-drafter for details.
>>
>> We can tweak further one and reconsider if this becomes a real issue.
>> Konrad
>>
>>> On 5. Oct 2026, at 18:52, Jörg Hoh via dev <de...@sling.apache.org> wrote:
>>>
>>> H Konrad,
>>>
>>> Am Mo., 5. Okt. 2026 um 12:10 Uhr schrieb Konrad Windszus
>> <kw...@apache.org>:
>>>
>>>>
>>>> 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) [...]
>>>
>>>
>>> Yes, for sure. But even today the ability to directly push to the main
>>> branch (without PR and without Jira) is a problem, because that commit
>>> often goes unnoticed (if you are not closely following the commit
>> mails),
>>> and they never show up in the release notes!
>>>
>>> I am indifferent if (or if not) we want to be able to push to the main
>>> branch directly. But we should change the way release notes are
>> generated,
>>> and pull them directly from the history of the main branch (instead of
>>> relying on PRs) to improve the situation.
>>>
>>> (Of course that's a different aspect, and totally unrelated to GH issues
>> vs
>>> Jira.)
>>>
>>> Jörg
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
RE: [RT] Switch to github issues
Posted by Stefan Seifert via dev <de...@sling.apache.org>.
i also vote for creating release notes based on PRs - this should cover all relevant changes and is most helpful for the users.
at the same time, I also agree that committing directly the master branch should be done as rarely as possible and only for really cosmetic stuff - e.g. fixing a typo in a javadoc comment - and not for anything relevant, esp. not for actual changes in the (non-test) code. dependency updates (driven by renovate or manually), parent POM updates etc. should be done with a PR.
if we apply labels to PRs (e.g. a label for dependency updates, bug, features), we can create nicely grouped changelogs based on the PRs.
stefan
> -----Original Message-----
> From: Konrad Windszus <kw...@apache.org>
> Sent: Monday, October 5, 2026 8:01 PM
> To: dev@sling.apache.org
> Cc: Jörg Hoh <jh...@googlemail.com>
> Subject: Re: [RT] Switch to github issues
>
> Hi Jörg,
> Deriving release notes from commits only lack important classification
> from labels given to PRs.
> Also commit message are usually a bit more technical and also verbose than
> what you want to appear in release notes.
> Also some features/bugfixes are comprised of multiple commits.
>
> I would suggest to start trying it out like Maven does. Look at
> https://github.com/apache/maven-gh-actions-
> shared/blob/v5/.github/workflows/release-drafter.yml and
> https://github.com/release-drafter/release-drafter for details.
>
> We can tweak further one and reconsider if this becomes a real issue.
> Konrad
>
> > On 5. Oct 2026, at 18:52, Jörg Hoh via dev <de...@sling.apache.org> wrote:
> >
> > H Konrad,
> >
> > Am Mo., 5. Okt. 2026 um 12:10 Uhr schrieb Konrad Windszus
> <kw...@apache.org>:
> >
> >>
> >> 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) [...]
> >
> >
> > Yes, for sure. But even today the ability to directly push to the main
> > branch (without PR and without Jira) is a problem, because that commit
> > often goes unnoticed (if you are not closely following the commit
> mails),
> > and they never show up in the release notes!
> >
> > I am indifferent if (or if not) we want to be able to push to the main
> > branch directly. But we should change the way release notes are
> generated,
> > and pull them directly from the history of the main branch (instead of
> > relying on PRs) to improve the situation.
> >
> > (Of course that's a different aspect, and totally unrelated to GH issues
> vs
> > Jira.)
> >
> > Jörg
Re: [RT] Switch to github issues
Posted by Konrad Windszus <kw...@apache.org>.
Hi Jörg,
Deriving release notes from commits only lack important classification from labels given to PRs.
Also commit message are usually a bit more technical and also verbose than what you want to appear in release notes.
Also some features/bugfixes are comprised of multiple commits.
I would suggest to start trying it out like Maven does. Look at https://github.com/apache/maven-gh-actions-shared/blob/v5/.github/workflows/release-drafter.yml and https://github.com/release-drafter/release-drafter for details.
We can tweak further one and reconsider if this becomes a real issue.
Konrad
> On 5. Oct 2026, at 18:52, Jörg Hoh via dev <de...@sling.apache.org> wrote:
>
> H Konrad,
>
> Am Mo., 5. Okt. 2026 um 12:10 Uhr schrieb Konrad Windszus <kw...@apache.org>:
>
>>
>> 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) [...]
>
>
> Yes, for sure. But even today the ability to directly push to the main
> branch (without PR and without Jira) is a problem, because that commit
> often goes unnoticed (if you are not closely following the commit mails),
> and they never show up in the release notes!
>
> I am indifferent if (or if not) we want to be able to push to the main
> branch directly. But we should change the way release notes are generated,
> and pull them directly from the history of the main branch (instead of
> relying on PRs) to improve the situation.
>
> (Of course that's a different aspect, and totally unrelated to GH issues vs
> Jira.)
>
> Jörg
Re: [RT] Switch to github issues
Posted by Jörg Hoh via dev <de...@sling.apache.org>.
H Konrad,
Am Mo., 5. Okt. 2026 um 12:10 Uhr schrieb Konrad Windszus <kw...@apache.org>:
>
> 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) [...]
Yes, for sure. But even today the ability to directly push to the main
branch (without PR and without Jira) is a problem, because that commit
often goes unnoticed (if you are not closely following the commit mails),
and they never show up in the release notes!
I am indifferent if (or if not) we want to be able to push to the main
branch directly. But we should change the way release notes are generated,
and pull them directly from the history of the main branch (instead of
relying on PRs) to improve the situation.
(Of course that's a different aspect, and totally unrelated to GH issues vs
Jira.)
Jörg
Re: [RT] Switch to github issues
Posted by Konrad Windszus <kw...@apache.org>.
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 <de...@sling.apache.org> 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 <
> cziegeler@apache.org>:
>
>> 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
>> cziegeler@apache.org
>>
>>
>
> --
> https://cqdump.joerghoh.de
Re: [RT] Switch to github issues
Posted by Jörg Hoh via dev <de...@sling.apache.org>.
+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 <
cziegeler@apache.org>:
> 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
> cziegeler@apache.org
>
>
--
https://cqdump.joerghoh.de
RE: [RT] Switch to github issues
Posted by Stefan Seifert via dev <de...@sling.apache.org>.
+1 from my side for this proposal.
i see no benefit in trying to migrate all JIRA issues to github issues, even if we find a way to match each of those issues to the github repo it belongs.
in JIRA, we may want to find a way to communicate why there is no "create" button any more - although most people will probably just naturally go for github issues, once we make this option available in github (currently, it's disabled there).
stefan
> -----Original Message-----
> From: Carsten Ziegeler <cz...@apache.org>
> Sent: Thursday, October 1, 2026 4:42 PM
> To: dev@sling.apache.org
> Subject: [RT] Switch to github issues
>
> 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
> cziegeler@apache.org