Please let me know if you need any help here. On Thu, Feb 19, 2026 at 11:20 PM Havret <[email protected]> wrote:
> If it’s up to me, I’m definitely in favor of switching to GitHub Issues. > > KP > > On Thu, Feb 19, 2026 at 10:27 PM Vilius Šumskas via dev < > [email protected]> wrote: > > > Nice! > > > > Will all old Jira issues be migrated to GitHub too? > > > > Also, I'm wondering, how "stale" issues will be managed? I would hate to > > see those bots automatically closing issues if they are "inactive". I > > understand that sometimes there is a need to manage a backlog, but this > > doesn't allow "voting" on issues with likes or other means of activity > > other than "me too, please reopen" comments. > > > > -- > > Best Regards, > > Vilius > > > > -----Original Message----- > > From: Jean-Baptiste Onofré <[email protected]> > > Sent: Thursday, February 19, 2026 6:42 PM > > To: [email protected]; [email protected] > > Subject: GitHub Issues & Discussions enabled > > > > Hi folks, > > > > We are pleased to announce that GitHub Issues & Discussions. > > > > 1. GitHub Issues (https://github.com/apache/activemq/issues) > > Jira is now read-only and we should now all use GitHub Issues. > > > > We have the following labels available: > > - bug: for bug reports > > - dependencies: for dependencies updates > > - enhancement: for improvements on existing code > > - feature: for a complete new features > > - proposal: for a design proposal, big features > > - stale: when the issue is "inactive" for more than 60 days > > > > Please use these labels to classify the issues. > > > > When you create a PR, you can associate it with an issue either in the > > GitHub UI or using "This closes #xxxx" in the comments. > > I also suggest using conventional commit messages in PR with the format > > <type>(<scope>): <subject> where scope is optional. The type can be: > > - feat: (a new feature is introduced with the changes) > > - fix: (bug fix has occurred, not a fix to a build script) > > - docs: (changes to the documentation) > > - style: (formatting, missing semicolons, etc; no production code change) > > - refactor: (refactoring production code, eg. renaming a variable) > > - test: (adding missing tests, refactoring tests; no production code > > change) > > - chore: (changes that do not relate to a fix or feature and don't modify > > src or test files (for example updating dependencies or change in > > production code)) > > - perf – (performance improvements) > > - ci – (continuous integration related) > > - build – (changes that affect the build system or external dependencies) > > - revert – (reverts a previous commit) > > That's a nice practice because GitHub can use that to create nice Release > > Notes. > > Thanks to that, it's not necessary to create GH issues for all changes. > > > > For versions, we are using GitHub Projects ( > > https://github.com/apache/activemq/projects?query=is%3Aopen). > > You can assign several projects/versions per issue, and track the status > > of the versions. > > > > 2. GitHub Discussions > > We also enabled GitHub Discussions where we can have technical > discussions. > > The GH Discussions are automatically going to the dev@ mailing list. > > > > Let us know if you have any questions. > > > > Regards > > JB > > >
