[DISCUSS] Migrate from Jira to GitHub Issues

[Justin Bertram <jb...@apache.org>]

There's been a few threads about this general subject, but most have
concentrated on Classic in particular. I think it's worth discussing
migration of ActiveMQ as a whole and diving a bit deeper into the details
of why a migration makes (or doesn't make) sense and what the challenges
may be.

To this end I've put together this document [1]. I hope it will be of
service to the community as we consider this option.


Justin

[1]
https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Loris Boiteux <lo...@gmail.com>]

Hello

+1 nice move

Le mar. 16 déc. 2025 à 09:03, Francois Papon <fr...@openobject.fr>
a écrit :

> +1 for github issues!
>
> François
> fpapon@apache.org
> francois.papon@openobject.fr
>
> Le 15/12/2025 à 09:57, Jean-Baptiste Onofré a écrit :
> > Hi everyone,
> >
> > I would like to re-open the discussion regarding migrating from Jira to
> > GitHub Issues.
> >
> > I recently created a pull request to move our PR checks from Jenkins to
> > GitHub Actions (https://github.com/apache/activemq/pull/1497). This
> change
> > significantly improves build/test time and enables easier dependency
> > updates via Dependabot. I will continue working with Jean-Louis to
> > stabilize and improve the tests.
> >
> > Given the improved integration with GitHub Actions, and the availability
> of
> > a new migration script from ASF Infra, I believe it is a good time to
> > reconsider this move. Many other Apache projects have made this
> transition
> > successfully.
> >
> > I am +1 for adopting GitHub Issues and GitHub Actions.
> >
> > What are your thoughts?
> >
> > Regards,
> > JB
> >
> > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org>
> wrote:
> >
> >> There's been a few threads about this general subject, but most have
> >> concentrated on Classic in particular. I think it's worth discussing
> >> migration of ActiveMQ as a whole and diving a bit deeper into the
> details
> >> of why a migration makes (or doesn't make) sense and what the challenges
> >> may be.
> >>
> >> To this end I've put together this document [1]. I hope it will be of
> >> service to the community as we consider this option.
> >>
> >>
> >> Justin
> >>
> >> [1]
> >>
> >>
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Francois Papon <fr...@openobject.fr>]

+1 for github issues!

François
fpapon@apache.org
francois.papon@openobject.fr

Le 15/12/2025 à 09:57, Jean-Baptiste Onofré a écrit :
> Hi everyone,
>
> I would like to re-open the discussion regarding migrating from Jira to
> GitHub Issues.
>
> I recently created a pull request to move our PR checks from Jenkins to
> GitHub Actions (https://github.com/apache/activemq/pull/1497). This change
> significantly improves build/test time and enables easier dependency
> updates via Dependabot. I will continue working with Jean-Louis to
> stabilize and improve the tests.
>
> Given the improved integration with GitHub Actions, and the availability of
> a new migration script from ASF Infra, I believe it is a good time to
> reconsider this move. Many other Apache projects have made this transition
> successfully.
>
> I am +1 for adopting GitHub Issues and GitHub Actions.
>
> What are your thoughts?
>
> Regards,
> JB
>
> On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org> wrote:
>
>> There's been a few threads about this general subject, but most have
>> concentrated on Classic in particular. I think it's worth discussing
>> migration of ActiveMQ as a whole and diving a bit deeper into the details
>> of why a migration makes (or doesn't make) sense and what the challenges
>> may be.
>>
>> To this end I've put together this document [1]. I hope it will be of
>> service to the community as we consider this option.
>>
>>
>> Justin
>>
>> [1]
>>
>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Ken Liao <ke...@gmail.com>]

+1 for github actions.

Agree with points provided.

Thanks,
Ken

On Mon, Dec 15, 2025 at 9:29 AM Cesar Hernandez <ce...@gmail.com>
wrote:

> +1 for github actions.
> It improves the traceability between branches, commits, PRs, and GitHub
> issues.
> It also opens the opportunity to document each release in the
> https://github.com/apache/activemq/releases
>
> On Mon, Dec 15, 2025 at 10:44 AM Matt Pavlovich <ma...@apache.org>
> wrote:
>
> > +1
> >
> > I am good with one vote for all three items
> >
> > Reminder— The Jenkinsfile should not be removed— it is still use it for
> > the s390x test builds.
> >
> > Thanks,
> > Matt
> >
> > > On Dec 15, 2025, at 9:43 AM, Justin Bertram <jb...@apache.org>
> wrote:
> > >
> > > Is there a specific connection between using GHA, Dependabot, and
> GitHub
> > > Issues other than they are all services provided by GitHub? Each of
> these
> > > seems like independent discussions that shouldn't necessarily be
> > conflated.
> > >
> > > Regarding GitHub Issues specifically, it's not clear what substantive
> and
> > > relevant changes have occurred since the last time we had this
> > discussion.
> > >
> > > In any case, can you provide any further details about the "new
> migration
> > > script from ASF Infra"? What exactly does it do? I
> > >
> > >
> > > Justin
> > >
> > > On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > > wrote:
> > >
> > >> Hi everyone,
> > >>
> > >> I would like to re-open the discussion regarding migrating from Jira
> to
> > >> GitHub Issues.
> > >>
> > >> I recently created a pull request to move our PR checks from Jenkins
> to
> > >> GitHub Actions (https://github.com/apache/activemq/pull/1497). This
> > change
> > >> significantly improves build/test time and enables easier dependency
> > >> updates via Dependabot. I will continue working with Jean-Louis to
> > >> stabilize and improve the tests.
> > >>
> > >> Given the improved integration with GitHub Actions, and the
> > availability of
> > >> a new migration script from ASF Infra, I believe it is a good time to
> > >> reconsider this move. Many other Apache projects have made this
> > transition
> > >> successfully.
> > >>
> > >> I am +1 for adopting GitHub Issues and GitHub Actions.
> > >>
> > >> What are your thoughts?
> > >>
> > >> Regards,
> > >> JB
> > >>
> > >> On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org>
> > wrote:
> > >>
> > >>> There's been a few threads about this general subject, but most have
> > >>> concentrated on Classic in particular. I think it's worth discussing
> > >>> migration of ActiveMQ as a whole and diving a bit deeper into the
> > details
> > >>> of why a migration makes (or doesn't make) sense and what the
> > challenges
> > >>> may be.
> > >>>
> > >>> To this end I've put together this document [1]. I hope it will be of
> > >>> service to the community as we consider this option.
> > >>>
> > >>>
> > >>> Justin
> > >>>
> > >>> [1]
> > >>>
> > >>>
> > >>
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > >>>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: dev-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> >
> >
> >
>
> --
> Atentamente:
> César Hernández.
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Cesar Hernandez <ce...@gmail.com>]

+1 for github actions.
It improves the traceability between branches, commits, PRs, and GitHub
issues.
It also opens the opportunity to document each release in the
https://github.com/apache/activemq/releases

On Mon, Dec 15, 2025 at 10:44 AM Matt Pavlovich <ma...@apache.org> wrote:

> +1
>
> I am good with one vote for all three items
>
> Reminder— The Jenkinsfile should not be removed— it is still use it for
> the s390x test builds.
>
> Thanks,
> Matt
>
> > On Dec 15, 2025, at 9:43 AM, Justin Bertram <jb...@apache.org> wrote:
> >
> > Is there a specific connection between using GHA, Dependabot, and GitHub
> > Issues other than they are all services provided by GitHub? Each of these
> > seems like independent discussions that shouldn't necessarily be
> conflated.
> >
> > Regarding GitHub Issues specifically, it's not clear what substantive and
> > relevant changes have occurred since the last time we had this
> discussion.
> >
> > In any case, can you provide any further details about the "new migration
> > script from ASF Infra"? What exactly does it do? I
> >
> >
> > Justin
> >
> > On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> >
> >> Hi everyone,
> >>
> >> I would like to re-open the discussion regarding migrating from Jira to
> >> GitHub Issues.
> >>
> >> I recently created a pull request to move our PR checks from Jenkins to
> >> GitHub Actions (https://github.com/apache/activemq/pull/1497). This
> change
> >> significantly improves build/test time and enables easier dependency
> >> updates via Dependabot. I will continue working with Jean-Louis to
> >> stabilize and improve the tests.
> >>
> >> Given the improved integration with GitHub Actions, and the
> availability of
> >> a new migration script from ASF Infra, I believe it is a good time to
> >> reconsider this move. Many other Apache projects have made this
> transition
> >> successfully.
> >>
> >> I am +1 for adopting GitHub Issues and GitHub Actions.
> >>
> >> What are your thoughts?
> >>
> >> Regards,
> >> JB
> >>
> >> On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org>
> wrote:
> >>
> >>> There's been a few threads about this general subject, but most have
> >>> concentrated on Classic in particular. I think it's worth discussing
> >>> migration of ActiveMQ as a whole and diving a bit deeper into the
> details
> >>> of why a migration makes (or doesn't make) sense and what the
> challenges
> >>> may be.
> >>>
> >>> To this end I've put together this document [1]. I hope it will be of
> >>> service to the community as we consider this option.
> >>>
> >>>
> >>> Justin
> >>>
> >>> [1]
> >>>
> >>>
> >>
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

-- 
Atentamente:
César Hernández.

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@apache.org>]

+1

I am good with one vote for all three items

Reminder— The Jenkinsfile should not be removed— it is still use it for the s390x test builds.

Thanks,
Matt

> On Dec 15, 2025, at 9:43 AM, Justin Bertram <jb...@apache.org> wrote:
> 
> Is there a specific connection between using GHA, Dependabot, and GitHub
> Issues other than they are all services provided by GitHub? Each of these
> seems like independent discussions that shouldn't necessarily be conflated.
> 
> Regarding GitHub Issues specifically, it's not clear what substantive and
> relevant changes have occurred since the last time we had this discussion.
> 
> In any case, can you provide any further details about the "new migration
> script from ASF Infra"? What exactly does it do? I
> 
> 
> Justin
> 
> On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> 
>> Hi everyone,
>> 
>> I would like to re-open the discussion regarding migrating from Jira to
>> GitHub Issues.
>> 
>> I recently created a pull request to move our PR checks from Jenkins to
>> GitHub Actions (https://github.com/apache/activemq/pull/1497). This change
>> significantly improves build/test time and enables easier dependency
>> updates via Dependabot. I will continue working with Jean-Louis to
>> stabilize and improve the tests.
>> 
>> Given the improved integration with GitHub Actions, and the availability of
>> a new migration script from ASF Infra, I believe it is a good time to
>> reconsider this move. Many other Apache projects have made this transition
>> successfully.
>> 
>> I am +1 for adopting GitHub Issues and GitHub Actions.
>> 
>> What are your thoughts?
>> 
>> Regards,
>> JB
>> 
>> On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org> wrote:
>> 
>>> There's been a few threads about this general subject, but most have
>>> concentrated on Classic in particular. I think it's worth discussing
>>> migration of ActiveMQ as a whole and diving a bit deeper into the details
>>> of why a migration makes (or doesn't make) sense and what the challenges
>>> may be.
>>> 
>>> To this end I've put together this document [1]. I hope it will be of
>>> service to the community as we consider this option.
>>> 
>>> 
>>> Justin
>>> 
>>> [1]
>>> 
>>> 
>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Justin,

That was intentional: I wanted to bring the discussion about GitHub Issues
and GitHub Actions together due to the ongoing work on Actions.

I agree to split the discussions and, if needed, call for separate votes on
each topic.

Regards,
JB

On Tue, Dec 16, 2025 at 9:19 AM Justin Bertram <jb...@apache.org> wrote:

> I don't recall any questions about out issue tracker recently on the
> mailing lists or on Slack. Did I miss something? In any case, it's no
> secret as to why we're still using Jira. This subject has been discussed
> several times [1] [2] [3] [4], most recently on this very thread. Anybody
> whose been participating in the community would likely remember, and if not
> it's fairly easy to search it up.
>
> From a user's point-of-view I can certainly see why GitHub Issues would be
> appealing. All things being equal, I can see how it would appeal to
> maintainers as well. About 20 months ago I put together a document [5]
> outlining this migration discussion. However, nobody has, as of yet,
> proposed a credible, comprehensive plan addressing the migration
> challenges. It's easy to say "let's migrate," but without a plan I just
> don't see how we can responsibly evaluate the options. We need to agree
> upon and document workflows and conventions before the migration happens or
> things will almost certainly be a mess. This might not be a big deal for
> the average user or the occasional contributor, but for folks who work with
> this code-base and others like it on a daily basis it can make a
> significant difference. I'm going to update the review doc to clarify the
> challenges and to eliminate Artemis since it's not relevant to this
> discussion any longer.
>
> This thread was originally about migrating from Jira to GitHub Issues.
> However, the subject of GitHub Actions and Dependabot adoption has also now
> been raised and folks are responding independently about these subjects
> now. Although related, these really are independent subjects. It would be
> nice to keep them separate to simplify the issue-tracker discussion, if
> possible.
>
>
> Justin
>
> [1] https://lists.apache.org/thread/w3cl57zs7xmhk38mpzygp29whmmdbjkw
> [2] https://lists.apache.org/thread/zqp72y8jpsc4q9g9z4skxjyozxs8gr8r
> [3] https://lists.apache.org/thread/9ryfs0y8gnl2z4o2d7q646ffdrs9zzcp
> [4] https://lists.apache.org/thread/93v6b5xxmthsypcwgvhotsmm4y2whdkm
> [5]
>
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>
>
> On Tue, Dec 16, 2025 at 10:06 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > What we usually do is duplicate the issue with different target releases.
> >
> > Regards
> > JB
> >
> > On Tue, Dec 16, 2025 at 7:30 AM Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> >
> > > I am fine with switching if everyone else wants to (It doesn't matter
> to
> > me
> > > which one we use) but is there a good solution with GitHub issues for
> > > assigning issues to multiple releases? This came up before by Robbie
> who
> > > pointed out it's not great when doing multiple releases and backports.
> So
> > > we would need to decide how to handle that (maybe use labels or
> projects)
> > > because you can't assign multiple milestones to an issue.
> > >
> > > Chris
> > >
> > > On Tue, Dec 16, 2025 at 8:51 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > You are correct that there is no direct connection between GitHub
> > > > Actions/Dependabot and GitHub Issues, but the move towards using more
> > > > GitHub services provides a smoother integration experience overall.
> > > >
> > > > The primary reason for revisiting this discussion now is the
> increasing
> > > > number of requests from contributors asking why we are still using
> > Jira.
> > > > This, coupled with the work on GitHub Actions, suggests that the
> timing
> > > is
> > > > right to reconsider the switch.
> > > >
> > > > The ASF Infrastructure tool for migration is available here:
> > > > https://github.com/apache/infrastructure-jira-issues-importer
> > > >
> > > > Based on the feedback in this thread, it appears we are moving
> towards
> > a
> > > > consensus for adopting GitHub Issues.
> > > >
> > > > Regards,
> > > > JB
> > > >
> > > > On Mon, Dec 15, 2025 at 7:43 AM Justin Bertram <jb...@apache.org>
> > > > wrote:
> > > >
> > > > > Is there a specific connection between using GHA, Dependabot, and
> > > GitHub
> > > > > Issues other than they are all services provided by GitHub? Each of
> > > these
> > > > > seems like independent discussions that shouldn't necessarily be
> > > > conflated.
> > > > >
> > > > > Regarding GitHub Issues specifically, it's not clear what
> substantive
> > > and
> > > > > relevant changes have occurred since the last time we had this
> > > > discussion.
> > > > >
> > > > > In any case, can you provide any further details about the "new
> > > migration
> > > > > script from ASF Infra"? What exactly does it do? I
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > > On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <
> > jb@nanthrax.net>
> > > > > wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > I would like to re-open the discussion regarding migrating from
> > Jira
> > > to
> > > > > > GitHub Issues.
> > > > > >
> > > > > > I recently created a pull request to move our PR checks from
> > Jenkins
> > > to
> > > > > > GitHub Actions (https://github.com/apache/activemq/pull/1497).
> > This
> > > > > change
> > > > > > significantly improves build/test time and enables easier
> > dependency
> > > > > > updates via Dependabot. I will continue working with Jean-Louis
> to
> > > > > > stabilize and improve the tests.
> > > > > >
> > > > > > Given the improved integration with GitHub Actions, and the
> > > > availability
> > > > > of
> > > > > > a new migration script from ASF Infra, I believe it is a good
> time
> > to
> > > > > > reconsider this move. Many other Apache projects have made this
> > > > > transition
> > > > > > successfully.
> > > > > >
> > > > > > I am +1 for adopting GitHub Issues and GitHub Actions.
> > > > > >
> > > > > > What are your thoughts?
> > > > > >
> > > > > > Regards,
> > > > > > JB
> > > > > >
> > > > > > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <
> jbertram@apache.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > > There's been a few threads about this general subject, but most
> > > have
> > > > > > > concentrated on Classic in particular. I think it's worth
> > > discussing
> > > > > > > migration of ActiveMQ as a whole and diving a bit deeper into
> the
> > > > > details
> > > > > > > of why a migration makes (or doesn't make) sense and what the
> > > > > challenges
> > > > > > > may be.
> > > > > > >
> > > > > > > To this end I've put together this document [1]. I hope it will
> > be
> > > of
> > > > > > > service to the community as we consider this option.
> > > > > > >
> > > > > > >
> > > > > > > Justin
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Justin Bertram <jb...@apache.org>]

I don't recall any questions about out issue tracker recently on the
mailing lists or on Slack. Did I miss something? In any case, it's no
secret as to why we're still using Jira. This subject has been discussed
several times [1] [2] [3] [4], most recently on this very thread. Anybody
whose been participating in the community would likely remember, and if not
it's fairly easy to search it up.

From a user's point-of-view I can certainly see why GitHub Issues would be
appealing. All things being equal, I can see how it would appeal to
maintainers as well. About 20 months ago I put together a document [5]
outlining this migration discussion. However, nobody has, as of yet,
proposed a credible, comprehensive plan addressing the migration
challenges. It's easy to say "let's migrate," but without a plan I just
don't see how we can responsibly evaluate the options. We need to agree
upon and document workflows and conventions before the migration happens or
things will almost certainly be a mess. This might not be a big deal for
the average user or the occasional contributor, but for folks who work with
this code-base and others like it on a daily basis it can make a
significant difference. I'm going to update the review doc to clarify the
challenges and to eliminate Artemis since it's not relevant to this
discussion any longer.

This thread was originally about migrating from Jira to GitHub Issues.
However, the subject of GitHub Actions and Dependabot adoption has also now
been raised and folks are responding independently about these subjects
now. Although related, these really are independent subjects. It would be
nice to keep them separate to simplify the issue-tracker discussion, if
possible.


Justin

[1] https://lists.apache.org/thread/w3cl57zs7xmhk38mpzygp29whmmdbjkw
[2] https://lists.apache.org/thread/zqp72y8jpsc4q9g9z4skxjyozxs8gr8r
[3] https://lists.apache.org/thread/9ryfs0y8gnl2z4o2d7q646ffdrs9zzcp
[4] https://lists.apache.org/thread/93v6b5xxmthsypcwgvhotsmm4y2whdkm
[5]
https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review


On Tue, Dec 16, 2025 at 10:06 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> What we usually do is duplicate the issue with different target releases.
>
> Regards
> JB
>
> On Tue, Dec 16, 2025 at 7:30 AM Christopher Shannon <
> christopher.l.shannon@gmail.com> wrote:
>
> > I am fine with switching if everyone else wants to (It doesn't matter to
> me
> > which one we use) but is there a good solution with GitHub issues for
> > assigning issues to multiple releases? This came up before by Robbie who
> > pointed out it's not great when doing multiple releases and backports. So
> > we would need to decide how to handle that (maybe use labels or projects)
> > because you can't assign multiple milestones to an issue.
> >
> > Chris
> >
> > On Tue, Dec 16, 2025 at 8:51 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> >
> > > Hi,
> > >
> > > You are correct that there is no direct connection between GitHub
> > > Actions/Dependabot and GitHub Issues, but the move towards using more
> > > GitHub services provides a smoother integration experience overall.
> > >
> > > The primary reason for revisiting this discussion now is the increasing
> > > number of requests from contributors asking why we are still using
> Jira.
> > > This, coupled with the work on GitHub Actions, suggests that the timing
> > is
> > > right to reconsider the switch.
> > >
> > > The ASF Infrastructure tool for migration is available here:
> > > https://github.com/apache/infrastructure-jira-issues-importer
> > >
> > > Based on the feedback in this thread, it appears we are moving towards
> a
> > > consensus for adopting GitHub Issues.
> > >
> > > Regards,
> > > JB
> > >
> > > On Mon, Dec 15, 2025 at 7:43 AM Justin Bertram <jb...@apache.org>
> > > wrote:
> > >
> > > > Is there a specific connection between using GHA, Dependabot, and
> > GitHub
> > > > Issues other than they are all services provided by GitHub? Each of
> > these
> > > > seems like independent discussions that shouldn't necessarily be
> > > conflated.
> > > >
> > > > Regarding GitHub Issues specifically, it's not clear what substantive
> > and
> > > > relevant changes have occurred since the last time we had this
> > > discussion.
> > > >
> > > > In any case, can you provide any further details about the "new
> > migration
> > > > script from ASF Infra"? What exactly does it do? I
> > > >
> > > >
> > > > Justin
> > > >
> > > > On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <
> jb@nanthrax.net>
> > > > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > I would like to re-open the discussion regarding migrating from
> Jira
> > to
> > > > > GitHub Issues.
> > > > >
> > > > > I recently created a pull request to move our PR checks from
> Jenkins
> > to
> > > > > GitHub Actions (https://github.com/apache/activemq/pull/1497).
> This
> > > > change
> > > > > significantly improves build/test time and enables easier
> dependency
> > > > > updates via Dependabot. I will continue working with Jean-Louis to
> > > > > stabilize and improve the tests.
> > > > >
> > > > > Given the improved integration with GitHub Actions, and the
> > > availability
> > > > of
> > > > > a new migration script from ASF Infra, I believe it is a good time
> to
> > > > > reconsider this move. Many other Apache projects have made this
> > > > transition
> > > > > successfully.
> > > > >
> > > > > I am +1 for adopting GitHub Issues and GitHub Actions.
> > > > >
> > > > > What are your thoughts?
> > > > >
> > > > > Regards,
> > > > > JB
> > > > >
> > > > > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jbertram@apache.org
> >
> > > > wrote:
> > > > >
> > > > > > There's been a few threads about this general subject, but most
> > have
> > > > > > concentrated on Classic in particular. I think it's worth
> > discussing
> > > > > > migration of ActiveMQ as a whole and diving a bit deeper into the
> > > > details
> > > > > > of why a migration makes (or doesn't make) sense and what the
> > > > challenges
> > > > > > may be.
> > > > > >
> > > > > > To this end I've put together this document [1]. I hope it will
> be
> > of
> > > > > > service to the community as we consider this option.
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

What we usually do is duplicate the issue with different target releases.

Regards
JB

On Tue, Dec 16, 2025 at 7:30 AM Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:

> I am fine with switching if everyone else wants to (It doesn't matter to me
> which one we use) but is there a good solution with GitHub issues for
> assigning issues to multiple releases? This came up before by Robbie who
> pointed out it's not great when doing multiple releases and backports. So
> we would need to decide how to handle that (maybe use labels or projects)
> because you can't assign multiple milestones to an issue.
>
> Chris
>
> On Tue, Dec 16, 2025 at 8:51 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Hi,
> >
> > You are correct that there is no direct connection between GitHub
> > Actions/Dependabot and GitHub Issues, but the move towards using more
> > GitHub services provides a smoother integration experience overall.
> >
> > The primary reason for revisiting this discussion now is the increasing
> > number of requests from contributors asking why we are still using Jira.
> > This, coupled with the work on GitHub Actions, suggests that the timing
> is
> > right to reconsider the switch.
> >
> > The ASF Infrastructure tool for migration is available here:
> > https://github.com/apache/infrastructure-jira-issues-importer
> >
> > Based on the feedback in this thread, it appears we are moving towards a
> > consensus for adopting GitHub Issues.
> >
> > Regards,
> > JB
> >
> > On Mon, Dec 15, 2025 at 7:43 AM Justin Bertram <jb...@apache.org>
> > wrote:
> >
> > > Is there a specific connection between using GHA, Dependabot, and
> GitHub
> > > Issues other than they are all services provided by GitHub? Each of
> these
> > > seems like independent discussions that shouldn't necessarily be
> > conflated.
> > >
> > > Regarding GitHub Issues specifically, it's not clear what substantive
> and
> > > relevant changes have occurred since the last time we had this
> > discussion.
> > >
> > > In any case, can you provide any further details about the "new
> migration
> > > script from ASF Infra"? What exactly does it do? I
> > >
> > >
> > > Justin
> > >
> > > On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I would like to re-open the discussion regarding migrating from Jira
> to
> > > > GitHub Issues.
> > > >
> > > > I recently created a pull request to move our PR checks from Jenkins
> to
> > > > GitHub Actions (https://github.com/apache/activemq/pull/1497). This
> > > change
> > > > significantly improves build/test time and enables easier dependency
> > > > updates via Dependabot. I will continue working with Jean-Louis to
> > > > stabilize and improve the tests.
> > > >
> > > > Given the improved integration with GitHub Actions, and the
> > availability
> > > of
> > > > a new migration script from ASF Infra, I believe it is a good time to
> > > > reconsider this move. Many other Apache projects have made this
> > > transition
> > > > successfully.
> > > >
> > > > I am +1 for adopting GitHub Issues and GitHub Actions.
> > > >
> > > > What are your thoughts?
> > > >
> > > > Regards,
> > > > JB
> > > >
> > > > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org>
> > > wrote:
> > > >
> > > > > There's been a few threads about this general subject, but most
> have
> > > > > concentrated on Classic in particular. I think it's worth
> discussing
> > > > > migration of ActiveMQ as a whole and diving a bit deeper into the
> > > details
> > > > > of why a migration makes (or doesn't make) sense and what the
> > > challenges
> > > > > may be.
> > > > >
> > > > > To this end I've put together this document [1]. I hope it will be
> of
> > > > > service to the community as we consider this option.
> > > > >
> > > > >
> > > > > Justin
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@apache.org>]

Projects replace Milestones when you want to assign an issue to a specific release. PRs are linked to branches so those would be 1:1

Example:

Projects: v6.3.0, v5.2.0

Issue #4324 
PR #6435 -> main (for v6.3.0)
PR #6233 -> activemq-5.20.x (for v5.20.0)

-Matt 

> On Dec 16, 2025, at 9:30 AM, Christopher Shannon <ch...@gmail.com> wrote:
> 
> I am fine with switching if everyone else wants to (It doesn't matter to me
> which one we use) but is there a good solution with GitHub issues for
> assigning issues to multiple releases? This came up before by Robbie who
> pointed out it's not great when doing multiple releases and backports. So
> we would need to decide how to handle that (maybe use labels or projects)
> because you can't assign multiple milestones to an issue.
> 
> Chris
> 
> On Tue, Dec 16, 2025 at 8:51 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> 
>> Hi,
>> 
>> You are correct that there is no direct connection between GitHub
>> Actions/Dependabot and GitHub Issues, but the move towards using more
>> GitHub services provides a smoother integration experience overall.
>> 
>> The primary reason for revisiting this discussion now is the increasing
>> number of requests from contributors asking why we are still using Jira.
>> This, coupled with the work on GitHub Actions, suggests that the timing is
>> right to reconsider the switch.
>> 
>> The ASF Infrastructure tool for migration is available here:
>> https://github.com/apache/infrastructure-jira-issues-importer
>> 
>> Based on the feedback in this thread, it appears we are moving towards a
>> consensus for adopting GitHub Issues.
>> 
>> Regards,
>> JB
>> 
>> On Mon, Dec 15, 2025 at 7:43 AM Justin Bertram <jb...@apache.org>
>> wrote:
>> 
>>> Is there a specific connection between using GHA, Dependabot, and GitHub
>>> Issues other than they are all services provided by GitHub? Each of these
>>> seems like independent discussions that shouldn't necessarily be
>> conflated.
>>> 
>>> Regarding GitHub Issues specifically, it's not clear what substantive and
>>> relevant changes have occurred since the last time we had this
>> discussion.
>>> 
>>> In any case, can you provide any further details about the "new migration
>>> script from ASF Infra"? What exactly does it do? I
>>> 
>>> 
>>> Justin
>>> 
>>> On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>> 
>>>> Hi everyone,
>>>> 
>>>> I would like to re-open the discussion regarding migrating from Jira to
>>>> GitHub Issues.
>>>> 
>>>> I recently created a pull request to move our PR checks from Jenkins to
>>>> GitHub Actions (https://github.com/apache/activemq/pull/1497). This
>>> change
>>>> significantly improves build/test time and enables easier dependency
>>>> updates via Dependabot. I will continue working with Jean-Louis to
>>>> stabilize and improve the tests.
>>>> 
>>>> Given the improved integration with GitHub Actions, and the
>> availability
>>> of
>>>> a new migration script from ASF Infra, I believe it is a good time to
>>>> reconsider this move. Many other Apache projects have made this
>>> transition
>>>> successfully.
>>>> 
>>>> I am +1 for adopting GitHub Issues and GitHub Actions.
>>>> 
>>>> What are your thoughts?
>>>> 
>>>> Regards,
>>>> JB
>>>> 
>>>> On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org>
>>> wrote:
>>>> 
>>>>> There's been a few threads about this general subject, but most have
>>>>> concentrated on Classic in particular. I think it's worth discussing
>>>>> migration of ActiveMQ as a whole and diving a bit deeper into the
>>> details
>>>>> of why a migration makes (or doesn't make) sense and what the
>>> challenges
>>>>> may be.
>>>>> 
>>>>> To this end I've put together this document [1]. I hope it will be of
>>>>> service to the community as we consider this option.
>>>>> 
>>>>> 
>>>>> Justin
>>>>> 
>>>>> [1]
>>>>> 
>>>>> 
>>>> 
>>> 
>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>>>>> 
>>>> 
>>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Christopher Shannon <ch...@gmail.com>]

I am fine with switching if everyone else wants to (It doesn't matter to me
which one we use) but is there a good solution with GitHub issues for
assigning issues to multiple releases? This came up before by Robbie who
pointed out it's not great when doing multiple releases and backports. So
we would need to decide how to handle that (maybe use labels or projects)
because you can't assign multiple milestones to an issue.

Chris

On Tue, Dec 16, 2025 at 8:51 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> Hi,
>
> You are correct that there is no direct connection between GitHub
> Actions/Dependabot and GitHub Issues, but the move towards using more
> GitHub services provides a smoother integration experience overall.
>
> The primary reason for revisiting this discussion now is the increasing
> number of requests from contributors asking why we are still using Jira.
> This, coupled with the work on GitHub Actions, suggests that the timing is
> right to reconsider the switch.
>
> The ASF Infrastructure tool for migration is available here:
> https://github.com/apache/infrastructure-jira-issues-importer
>
> Based on the feedback in this thread, it appears we are moving towards a
> consensus for adopting GitHub Issues.
>
> Regards,
> JB
>
> On Mon, Dec 15, 2025 at 7:43 AM Justin Bertram <jb...@apache.org>
> wrote:
>
> > Is there a specific connection between using GHA, Dependabot, and GitHub
> > Issues other than they are all services provided by GitHub? Each of these
> > seems like independent discussions that shouldn't necessarily be
> conflated.
> >
> > Regarding GitHub Issues specifically, it's not clear what substantive and
> > relevant changes have occurred since the last time we had this
> discussion.
> >
> > In any case, can you provide any further details about the "new migration
> > script from ASF Infra"? What exactly does it do? I
> >
> >
> > Justin
> >
> > On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I would like to re-open the discussion regarding migrating from Jira to
> > > GitHub Issues.
> > >
> > > I recently created a pull request to move our PR checks from Jenkins to
> > > GitHub Actions (https://github.com/apache/activemq/pull/1497). This
> > change
> > > significantly improves build/test time and enables easier dependency
> > > updates via Dependabot. I will continue working with Jean-Louis to
> > > stabilize and improve the tests.
> > >
> > > Given the improved integration with GitHub Actions, and the
> availability
> > of
> > > a new migration script from ASF Infra, I believe it is a good time to
> > > reconsider this move. Many other Apache projects have made this
> > transition
> > > successfully.
> > >
> > > I am +1 for adopting GitHub Issues and GitHub Actions.
> > >
> > > What are your thoughts?
> > >
> > > Regards,
> > > JB
> > >
> > > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org>
> > wrote:
> > >
> > > > There's been a few threads about this general subject, but most have
> > > > concentrated on Classic in particular. I think it's worth discussing
> > > > migration of ActiveMQ as a whole and diving a bit deeper into the
> > details
> > > > of why a migration makes (or doesn't make) sense and what the
> > challenges
> > > > may be.
> > > >
> > > > To this end I've put together this document [1]. I hope it will be of
> > > > service to the community as we consider this option.
> > > >
> > > >
> > > > Justin
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > > >
> > >
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi,

You are correct that there is no direct connection between GitHub
Actions/Dependabot and GitHub Issues, but the move towards using more
GitHub services provides a smoother integration experience overall.

The primary reason for revisiting this discussion now is the increasing
number of requests from contributors asking why we are still using Jira.
This, coupled with the work on GitHub Actions, suggests that the timing is
right to reconsider the switch.

The ASF Infrastructure tool for migration is available here:
https://github.com/apache/infrastructure-jira-issues-importer

Based on the feedback in this thread, it appears we are moving towards a
consensus for adopting GitHub Issues.

Regards,
JB

On Mon, Dec 15, 2025 at 7:43 AM Justin Bertram <jb...@apache.org> wrote:

> Is there a specific connection between using GHA, Dependabot, and GitHub
> Issues other than they are all services provided by GitHub? Each of these
> seems like independent discussions that shouldn't necessarily be conflated.
>
> Regarding GitHub Issues specifically, it's not clear what substantive and
> relevant changes have occurred since the last time we had this discussion.
>
> In any case, can you provide any further details about the "new migration
> script from ASF Infra"? What exactly does it do? I
>
>
> Justin
>
> On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Hi everyone,
> >
> > I would like to re-open the discussion regarding migrating from Jira to
> > GitHub Issues.
> >
> > I recently created a pull request to move our PR checks from Jenkins to
> > GitHub Actions (https://github.com/apache/activemq/pull/1497). This
> change
> > significantly improves build/test time and enables easier dependency
> > updates via Dependabot. I will continue working with Jean-Louis to
> > stabilize and improve the tests.
> >
> > Given the improved integration with GitHub Actions, and the availability
> of
> > a new migration script from ASF Infra, I believe it is a good time to
> > reconsider this move. Many other Apache projects have made this
> transition
> > successfully.
> >
> > I am +1 for adopting GitHub Issues and GitHub Actions.
> >
> > What are your thoughts?
> >
> > Regards,
> > JB
> >
> > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org>
> wrote:
> >
> > > There's been a few threads about this general subject, but most have
> > > concentrated on Classic in particular. I think it's worth discussing
> > > migration of ActiveMQ as a whole and diving a bit deeper into the
> details
> > > of why a migration makes (or doesn't make) sense and what the
> challenges
> > > may be.
> > >
> > > To this end I've put together this document [1]. I hope it will be of
> > > service to the community as we consider this option.
> > >
> > >
> > > Justin
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > >
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Sérgio Damo de Lemos <se...@gmail.com>]

+1 for using Github issues.

Regards,
Sérgio Lemos

Em seg., 15 de dez. de 2025 às 07:43, Justin Bertram <jb...@apache.org>
escreveu:

> Is there a specific connection between using GHA, Dependabot, and GitHub
> Issues other than they are all services provided by GitHub? Each of these
> seems like independent discussions that shouldn't necessarily be conflated.
>
> Regarding GitHub Issues specifically, it's not clear what substantive and
> relevant changes have occurred since the last time we had this discussion.
>
> In any case, can you provide any further details about the "new migration
> script from ASF Infra"? What exactly does it do? I
>
>
> Justin
>
> On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Hi everyone,
> >
> > I would like to re-open the discussion regarding migrating from Jira to
> > GitHub Issues.
> >
> > I recently created a pull request to move our PR checks from Jenkins to
> > GitHub Actions (https://github.com/apache/activemq/pull/1497). This
> change
> > significantly improves build/test time and enables easier dependency
> > updates via Dependabot. I will continue working with Jean-Louis to
> > stabilize and improve the tests.
> >
> > Given the improved integration with GitHub Actions, and the availability
> of
> > a new migration script from ASF Infra, I believe it is a good time to
> > reconsider this move. Many other Apache projects have made this
> transition
> > successfully.
> >
> > I am +1 for adopting GitHub Issues and GitHub Actions.
> >
> > What are your thoughts?
> >
> > Regards,
> > JB
> >
> > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org>
> wrote:
> >
> > > There's been a few threads about this general subject, but most have
> > > concentrated on Classic in particular. I think it's worth discussing
> > > migration of ActiveMQ as a whole and diving a bit deeper into the
> details
> > > of why a migration makes (or doesn't make) sense and what the
> challenges
> > > may be.
> > >
> > > To this end I've put together this document [1]. I hope it will be of
> > > service to the community as we consider this option.
> > >
> > >
> > > Justin
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > >
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Justin Bertram <jb...@apache.org>]

Is there a specific connection between using GHA, Dependabot, and GitHub
Issues other than they are all services provided by GitHub? Each of these
seems like independent discussions that shouldn't necessarily be conflated.

Regarding GitHub Issues specifically, it's not clear what substantive and
relevant changes have occurred since the last time we had this discussion.

In any case, can you provide any further details about the "new migration
script from ASF Infra"? What exactly does it do? I


Justin

On Mon, Dec 15, 2025 at 3:08 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> Hi everyone,
>
> I would like to re-open the discussion regarding migrating from Jira to
> GitHub Issues.
>
> I recently created a pull request to move our PR checks from Jenkins to
> GitHub Actions (https://github.com/apache/activemq/pull/1497). This change
> significantly improves build/test time and enables easier dependency
> updates via Dependabot. I will continue working with Jean-Louis to
> stabilize and improve the tests.
>
> Given the improved integration with GitHub Actions, and the availability of
> a new migration script from ASF Infra, I believe it is a good time to
> reconsider this move. Many other Apache projects have made this transition
> successfully.
>
> I am +1 for adopting GitHub Issues and GitHub Actions.
>
> What are your thoughts?
>
> Regards,
> JB
>
> On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org> wrote:
>
> > There's been a few threads about this general subject, but most have
> > concentrated on Classic in particular. I think it's worth discussing
> > migration of ActiveMQ as a whole and diving a bit deeper into the details
> > of why a migration makes (or doesn't make) sense and what the challenges
> > may be.
> >
> > To this end I've put together this document [1]. I hope it will be of
> > service to the community as we consider this option.
> >
> >
> > Justin
> >
> > [1]
> >
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Jean-Louis Monteiro <jl...@tomitribe.com>]

On the same page. Github issues are of course well integrated and most of
the time more convenient because on the same platform. No need to go and
connect to JIRA which is often slow btw.

So +1

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Mon, Dec 15, 2025 at 9:58 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> Hi everyone,
>
> I would like to re-open the discussion regarding migrating from Jira to
> GitHub Issues.
>
> I recently created a pull request to move our PR checks from Jenkins to
> GitHub Actions (https://github.com/apache/activemq/pull/1497). This change
> significantly improves build/test time and enables easier dependency
> updates via Dependabot. I will continue working with Jean-Louis to
> stabilize and improve the tests.
>
> Given the improved integration with GitHub Actions, and the availability of
> a new migration script from ASF Infra, I believe it is a good time to
> reconsider this move. Many other Apache projects have made this transition
> successfully.
>
> I am +1 for adopting GitHub Issues and GitHub Actions.
>
> What are your thoughts?
>
> Regards,
> JB
>
> On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org> wrote:
>
> > There's been a few threads about this general subject, but most have
> > concentrated on Classic in particular. I think it's worth discussing
> > migration of ActiveMQ as a whole and diving a bit deeper into the details
> > of why a migration makes (or doesn't make) sense and what the challenges
> > may be.
> >
> > To this end I've put together this document [1]. I hope it will be of
> > service to the community as we consider this option.
> >
> >
> > Justin
> >
> > [1]
> >
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi everyone,

I would like to re-open the discussion regarding migrating from Jira to
GitHub Issues.

I recently created a pull request to move our PR checks from Jenkins to
GitHub Actions (https://github.com/apache/activemq/pull/1497). This change
significantly improves build/test time and enables easier dependency
updates via Dependabot. I will continue working with Jean-Louis to
stabilize and improve the tests.

Given the improved integration with GitHub Actions, and the availability of
a new migration script from ASF Infra, I believe it is a good time to
reconsider this move. Many other Apache projects have made this transition
successfully.

I am +1 for adopting GitHub Issues and GitHub Actions.

What are your thoughts?

Regards,
JB

On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org> wrote:

> There's been a few threads about this general subject, but most have
> concentrated on Classic in particular. I think it's worth discussing
> migration of ActiveMQ as a whole and diving a bit deeper into the details
> of why a migration makes (or doesn't make) sense and what the challenges
> may be.
>
> To this end I've put together this document [1]. I hope it will be of
> service to the community as we consider this option.
>
>
> Justin
>
> [1]
>
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell <ro...@gmail.com>]

On Wed, 3 Apr 2024 at 21:14, Matt Pavlovich <ma...@gmail.com> wrote:
>
> Hello @dev-
>
> I argue that we are effectively already using GitHub for issues, JIRA is just getting a back-port sync of the discussion. The reality is that code-change discussions are occurring on the PRs, not in JIRA or mailing lists-- and that makes sense. It is far easier to have a discussion while referencing the line of code and providing a checklist of issues to resolve to the committer. The GitHub-to-JIRA synchronization is noisy and generates a lot of text in the JIRA comments that aren't really legible.
>

That argument seems centered on the code discussion on a PR being the
main interesting bit of a Jira / Issue. For me, and I expect a lot of
users, I'd say it is often rather more the initial description/report
for e.g what a bug is, the collating of the [often multiple and
separate] commits made to fix it, and the release version tracking,
that tend to be as much or more interesting aspect of a Jira than what
are often just 'working thoughts' comments on a PR to get from the
initial proposed change to whatever is pushed. For that stuff, indeed
the PR is often a better place for to see that in-context. This would
be true for me, and again I expect a lot of users, regardless whether
it was an Issue or a Jira being used to track things (or at least,
would be supposing people adequately xref commits/Issues to make up
for the limitations in Issues/PRs use of Milestones to track
versions...i.e they can only point to 1).

(On the comments, the Github updates on our Jira's go in as 'work log'
entries rather than regular comments, so they actually aren't in the
way normally)

> The JIRA issue-to-PR process is cumbersome, there's now even a "NO-JIRA" process to work around that reality -- and that has led to back-and-forth on certain issues that start NO-JIRA, and then need to have a JIRA created and vice-versa.
>

Thats been happening since before PRs were an option, started due to
direct commit/push behaviour where PRs wouldnt have existed anyway,
and could essentially still happen with Issues too depending on what
approach were to be decided on for Issue <-> PR relationship, i.e
whether an issue is always needed or if a PR alone is sufficient.

It was me that initially coined the NO-JIRA thing over at Qpid  > 10
years ago, as an escape for a commit hook that required a Jira ref, to
help prod people that were not creating Jiras for
actually-quite-important/notable changes out of pure laziness, and
make it clear it wasnt then 'just an oversight' it was omitted. Alas,
since the ASF operated on a single foundation-wide Subversion
repository at the time, and due to the way the hook had to actually
operate as a result, it was found to be too slow to justify applying
it to every commit at the ASF just for one/some projects benefit to
prod people to be less lazy, and so that side ultimately didnt happen.
The commit message bit stuck around though, migrated, and has over
time become just as abused as reference'less commit logs were. Doh :)

The equivalent while having Issues instead of Jira's would center
around deciding if we wanted to always have an Issue for a given
change even if a PR is being raised, given that whilst they do share a
number space they are still defaulted to mostly being distinct things
in the UI and URLs. I expect many people making changes often won't
bother to raise an Issue, just the PR (or again, sometimes neither).
Most people not interested in making changes (i.e most user reports)
will of course just raise an Issue alone. Often people will raise a
non-xref'd PR for the same thing even though the Issue exists, since
they didnt raise or notice that Issue themselves originally (same
happen with Jira's too). This is an annoyance I find with Issues and
PRs, sharing a number space and being treated similarly by many, while
still being considered quite separate especially in the UI and URls
(the main annoyance being Milestone handling, where you can only have
1, which I find it means most projects just have useless or no release
notes for their non-latest releases as a result, and you really just
need to look at the tags and commits to see what you need)


> Issues:
>  - Customizable templates that can enforce policy to reduce back-and-forth with in-experienced issue submitters.

I find those templates as much just increase the number of Issues
littered with templates not actually filled in.

>
> Release notes:
>  - Simple generation, template-izable and ability to customize at release time (ie to remove any NO-JIRA type things that don't need to be in release notes)
>
> In terms of migration complexity, I think the numbers make the migration effort look larger than the actual reality on the ground. We are really talking about 2 active repos (activemq & artemis) and 1 periodically updated repo (nms).
>
> Migration can be over time and on a project-by-project or repo-by-repo basis. The majority of total repo count are NMS related, and there is an argument that those should be combined to a single repo  for easier release. Using the top-level NMS project for issues and labels for sub-projects would be suitable for a low-traffic module such as that.
>

I dont think we should be combining things into aggregate repos again.
They essentially started that way and were split out along the lines
which they are independently developed and released. Given there are
really only 2 NMS clients and the NMS API getting any attention, and
really not much at that, I see no need to combine anything there.

> The activemq-cli-tools can move/migrate into the main ActiveMQ repo, its a simple tool and it makes sense to include that function in the distribution.
>

It was put in its own repo because it was applicable to / dependent on
both 5.x and Artemis, and so it could be independently updated and
released in cases where it needed updates from both...it's not clear
to me that moving it into one or the other broker repo makes sense any
more now than it did originally (supposing it were even being actively
updated, which it isnt).


> We've transitioned to a new era in software development, and we should move to the tools that are more readily used by dev-users in this era. That is currently GitHub. GitHub is a better toolkit for streamlining the management of the project and developing community engagement.
>
> Thank you for attending my TED talk,
> Matt Pavlovich
>
> > On Apr 2, 2024, at 2:52 PM, Justin Bertram <jb...@apache.org> wrote:
> >
> > There's been a few threads about this general subject, but most have
> > concentrated on Classic in particular. I think it's worth discussing
> > migration of ActiveMQ as a whole and diving a bit deeper into the details
> > of why a migration makes (or doesn't make) sense and what the challenges
> > may be.
> >
> > To this end I've put together this document [1]. I hope it will be of
> > service to the community as we consider this option.
> >
> >
> > Justin
> >
> > [1]
> > https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@gmail.com>]

Hello @dev-

I argue that we are effectively already using GitHub for issues, JIRA is just getting a back-port sync of the discussion. The reality is that code-change discussions are occurring on the PRs, not in JIRA or mailing lists-- and that makes sense. It is far easier to have a discussion while referencing the line of code and providing a checklist of issues to resolve to the committer. The GitHub-to-JIRA synchronization is noisy and generates a lot of text in the JIRA comments that aren't really legible.

The JIRA issue-to-PR process is cumbersome, there's now even a "NO-JIRA" process to work around that reality -- and that has led to back-and-forth on certain issues that start NO-JIRA, and then need to have a JIRA created and vice-versa.

Issues:
 - Customizable templates that can enforce policy to reduce back-and-forth with in-experienced issue submitters.

Release notes:
 - Simple generation, template-izable and ability to customize at release time (ie to remove any NO-JIRA type things that don't need to be in release notes)

In terms of migration complexity, I think the numbers make the migration effort look larger than the actual reality on the ground. We are really talking about 2 active repos (activemq & artemis) and 1 periodically updated repo (nms).

Migration can be over time and on a project-by-project or repo-by-repo basis. The majority of total repo count are NMS related, and there is an argument that those should be combined to a single repo  for easier release. Using the top-level NMS project for issues and labels for sub-projects would be suitable for a low-traffic module such as that.

The activemq-cli-tools can move/migrate into the main ActiveMQ repo, its a simple tool and it makes sense to include that function in the distribution.

We've transitioned to a new era in software development, and we should move to the tools that are more readily used by dev-users in this era. That is currently GitHub. GitHub is a better toolkit for streamlining the management of the project and developing community engagement.

Thank you for attending my TED talk,
Matt Pavlovich

> On Apr 2, 2024, at 2:52 PM, Justin Bertram <jb...@apache.org> wrote:
> 
> There's been a few threads about this general subject, but most have
> concentrated on Classic in particular. I think it's worth discussing
> migration of ActiveMQ as a whole and diving a bit deeper into the details
> of why a migration makes (or doesn't make) sense and what the challenges
> may be.
> 
> To this end I've put together this document [1]. I hope it will be of
> service to the community as we consider this option.
> 
> 
> Justin
> 
> [1]
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Bruce Snyder <br...@gmail.com>]

A big thank you to Justin for his effort to research and document this
topic and the options available! This info is very helpful to better
understand the scope of the situation.

Justin mentioned that he spends about 20 minutes per month on Jira account
approval, so there's not a tremendous time savings by off-loading issue
management to GitHub. Are there any other costs that we should consider in
terms of time? In fact, if we were to make this change, it might actually
require a lot more toil from the PMC to make the changes and manage the
situation in a new manner as well as from the users to understand the new
setup.

While I was one of the folks who angled toward a move from Jira to GitHub
for issue management, I'm not necessarily convinced that such a change will
result in the best user experience as well as decrease the work the PMC
does to manage Jira account requests. I was under the impression that the
Jira account management aspect cost more time than it does.

Bruce

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Justin Bertram <jb...@apache.org>]

> When users want Jira access, do they use an Apache account, or can it be
any account?

Folks who have an Apache account (e.g. committers, PMC members, etc.)
automatically have access to the ASF Jira instance.

> Or are we just creating jira-specific accounts for these users?

If you don't have an Apache account and you want to create a Jira, for
example, then you must request a Jira account. This is an account
specifically for the ASF Jira instance.

Lots of websites employ OAuth so that you can, for example, use your Google
account or Facebook account to access their services. That's not true of
ASF Jira. You must have a specific ASF Jira account.

> Do they have / need-to-have an ICLA signed and on-file?

No.

> It seems to me the real issue at heart here is avoiding spam, and using
authenticated users as a means to that end.  So, I'm trying to understand
whether that's feasible with Apache Jira.

As far as I know ASF Infra has _always_ required an account to create
Jiras, etc. However, that requirement still hasn't been sufficient to
prevent spam - even with a captcha for creating an account. Therefore, the
PMC now has to approve Jira account requests.


Justin

On Wed, Apr 3, 2024 at 11:10 AM Arthur Naseef <ar...@amlinv.com> wrote:

> I read through Justin's document up to the section "Why Use GitHub
> Issues?" and have questions.
>
> When users want Jira access, do they use an Apache account, or can it
> be any account?  Or are we just creating jira-specific accounts for
> these users?  Do they have / need-to-have an ICLA signed and on-file?
>
> It seems to me the real issue at heart here is avoiding spam, and
> using authenticated users as a means to that end.  So, I'm trying to
> understand whether that's feasible with Apache Jira.
>
> Art
>
> P.S. Nice write-up Justin - thank you!
>
> On Wed, Apr 3, 2024 at 2:16 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >
> > Hi Justin
> >
> > Fantastic work and great summary !
> >
> > I do a quick pass, I will do a more detailed read.
> >
> > Thanks !
> > Regards
> > JB
> >
> > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org>
> wrote:
> > >
> > > There's been a few threads about this general subject, but most have
> > > concentrated on Classic in particular. I think it's worth discussing
> > > migration of ActiveMQ as a whole and diving a bit deeper into the
> details
> > > of why a migration makes (or doesn't make) sense and what the
> challenges
> > > may be.
> > >
> > > To this end I've put together this document [1]. I hope it will be of
> > > service to the community as we consider this option.
> > >
> > >
> > > Justin
> > >
> > > [1]
> > >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Arthur Naseef <ar...@amlinv.com>]

I read through Justin's document up to the section "Why Use GitHub
Issues?" and have questions.

When users want Jira access, do they use an Apache account, or can it
be any account?  Or are we just creating jira-specific accounts for
these users?  Do they have / need-to-have an ICLA signed and on-file?

It seems to me the real issue at heart here is avoiding spam, and
using authenticated users as a means to that end.  So, I'm trying to
understand whether that's feasible with Apache Jira.

Art

P.S. Nice write-up Justin - thank you!

On Wed, Apr 3, 2024 at 2:16 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi Justin
>
> Fantastic work and great summary !
>
> I do a quick pass, I will do a more detailed read.
>
> Thanks !
> Regards
> JB
>
> On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org> wrote:
> >
> > There's been a few threads about this general subject, but most have
> > concentrated on Classic in particular. I think it's worth discussing
> > migration of ActiveMQ as a whole and diving a bit deeper into the details
> > of why a migration makes (or doesn't make) sense and what the challenges
> > may be.
> >
> > To this end I've put together this document [1]. I hope it will be of
> > service to the community as we consider this option.
> >
> >
> > Justin
> >
> > [1]
> > https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Justin

Fantastic work and great summary !

I do a quick pass, I will do a more detailed read.

Thanks !
Regards
JB

On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram <jb...@apache.org> wrote:
>
> There's been a few threads about this general subject, but most have
> concentrated on Classic in particular. I think it's worth discussing
> migration of ActiveMQ as a whole and diving a bit deeper into the details
> of why a migration makes (or doesn't make) sense and what the challenges
> may be.
>
> To this end I've put together this document [1]. I hope it will be of
> service to the community as we consider this option.
>
>
> Justin
>
> [1]
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell <ro...@gmail.com>]

On the lack of Issues tab, though it doesnt seem to have been too much
of an issue so far, we could certainly improve that by ensuring each
repo README always covers how to raise things (or just links to the
website page that covers it; I think some repos already do). Plus,
opening Discussions again might be a suitable alternative for many of
the things that get raised as issues but are actually just questions.

On Fri, 5 Apr 2024 at 17:15, Domenico Francesco Bruscino
<br...@gmail.com> wrote:
>
> I don't have a strong opinion on migrating from Jira to GitHub Issues.
> I would prefer GitHub Issues only for its better integration and because
> new users that reach from the GitHub repository could be confused to not
> find the `Issues` tabs (most of the GitHub projects use it).
>
> Also GitHub Issues has a good REST interface, I'm using it in
> GithubIssueManager[1].
>
> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
>
> [1]
> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
>
> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <cl...@gmail.com>
> wrote:
>
> > I would prefer to keep JIRA for their REST interface.
> >
> > Also: one thing to notice is the possibility of using private comments
> > in JIRA. Say you ever have a security issue. I think you can have PMC
> > private comments on JIRAs. I'm not sure you have the same in github
> > issues.
> >
> >
> > I didn't see a note about private comments on Justin's detailed doc
> > (nice Doc BTW), but the private comments may be handy on handling
> > sensitive issues.
> >
> > On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <ro...@gmail.com>
> > wrote:
> > >
> > > The 'track version as Project' thing is interesting, though kinda
> > > further underscores the limitations of Milestones which are really the
> > > main surfaced way of handling versions.
> > >
> > > I'll bet some folks on the 'users' side of things looking at released
> > > issues later would even miss that you are doing that (I would), since
> > > Projects are kinda separate and get even further hidden away upon
> > > completion; closed Projects are hidden/collapsed in the Issue/PR view
> > > on expectations they are no longer 'interesting', requiring you to
> > > spot that and expand the closed-projects view on each Issue/PR to see
> > > the Project later. Which to be fair I think is actually decent
> > > behaviour in general for their main use cases, since they aren't
> > > really aimed to be used as versions but more for using the 'swimlane'
> > > etc views given for managing/planning overall outstanding tasks to a
> > > point of completion and will then most typically be
> > > forgotten/less-interesting detail.
> > >
> > > On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> > > <ch...@gmail.com> wrote:
> > > >
> > > > I am also on the Accumulo PMC and on that project we use Github issues
> > > > and no longer use Jira. This switch was made before my time so I'm not
> > > > sure of the reasoning. Personally, I don't really care too much either
> > > > way as I've used both but I will just point out 2 things from my
> > > > experience with it.
> > > >
> > > > 1) For version tracking, we use projects and not milestones. I don't
> > > > know if this is the best way to do things but that's what we have been
> > > > using and seems to work ok as you can list multiple projects
> > > > (versions) for an Issue or PR:
> > > > https://github.com/apache/accumulo/projects?type=classic
> > > >
> > > > 2) Robbie's point about whether or not Issues get opened is a really
> > > > good point and something that is not consistent at all in Accumulo.
> > > > What I have found is it is all over the place. In some cases people
> > > > just open PRs and essentially are self documenting issues with the
> > > > fix. In other cases people open up issues and then open up PRs. It
> > > > does get confusing sometimes since they share the same numbering and
> > > > name space. It may make sense to try and establish some guidelines if
> > > > we go with Github Issues just so we are consistent about it.
> > > >
> > > > On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
> > wrote:
> > > > >
> > > > >
> > > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> > robbie.gemmell@gmail.com> wrote:
> > > > > >
> > > > > > To the later point around Discussions, I do think enabling those
> > could
> > > > > > be good either way since, just like with Jira, people will often
> > > > > > create Issues to ask questions rather than e.g mail a mailing list.
> > > > > > They might use a Discussion instead though.
> > > > >
> > > > > +1 agree that having discussions enabled would be an upgrade for
> > users, big improvement over mailing lists.
> > > > >
> > > > > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jb...@apache.org>
> > wrote:
> > > > > >>
> > > > > >> There's been a few threads about this general subject, but most
> > have
> > > > > >> concentrated on Classic in particular. I think it's worth
> > discussing
> > > > > >> migration of ActiveMQ as a whole and diving a bit deeper into the
> > details
> > > > > >> of why a migration makes (or doesn't make) sense and what the
> > challenges
> > > > > >> may be.
> > > > > >>
> > > > > >> To this end I've put together this document [1]. I hope it will
> > be of
> > > > > >> service to the community as we consider this option.
> > > > > >>
> > > > > >>
> > > > > >> Justin
> > > > > >>
> > > > > >> [1]
> > > > > >>
> > https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > > > >
> >
> >
> >
> > --
> > Clebert Suconic
> >

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell <ro...@gmail.com>]

Whilst Jira can certainly do that, I dont believe we have ever used it
in that fashion here, and so I dont see that it could be considered a
break either way. Also, the process of e.g privately reporting
security issues wouldnt change in any event, it would remain as it is
now (and is detailed on each github repository already due to some org
level defaults).

On Fri, 5 Apr 2024 at 17:48, Clebert Suconic <cl...@gmail.com> wrote:
>
> Is there a private comment capability on GitHub?  To me that’s a breaking
> deal feature and I have never seen it.
>
> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> bruscinodf@gmail.com> wrote:
>
> > I don't have a strong opinion on migrating from Jira to GitHub Issues.
> > I would prefer GitHub Issues only for its better integration and because
> > new users that reach from the GitHub repository could be confused to not
> > find the `Issues` tabs (most of the GitHub projects use it).
> >
> > Also GitHub Issues has a good REST interface, I'm using it in
> > GithubIssueManager[1].
> >
> > @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
> >
> > [1]
> >
> > https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >
> > On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <cl...@gmail.com>
> > wrote:
> >
> > > I would prefer to keep JIRA for their REST interface.
> > >
> > > Also: one thing to notice is the possibility of using private comments
> > > in JIRA. Say you ever have a security issue. I think you can have PMC
> > > private comments on JIRAs. I'm not sure you have the same in github
> > > issues.
> > >
> > >
> > > I didn't see a note about private comments on Justin's detailed doc
> > > (nice Doc BTW), but the private comments may be handy on handling
> > > sensitive issues.
> > >
> > > On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <ro...@gmail.com>
> > > wrote:
> > > >
> > > > The 'track version as Project' thing is interesting, though kinda
> > > > further underscores the limitations of Milestones which are really the
> > > > main surfaced way of handling versions.
> > > >
> > > > I'll bet some folks on the 'users' side of things looking at released
> > > > issues later would even miss that you are doing that (I would), since
> > > > Projects are kinda separate and get even further hidden away upon
> > > > completion; closed Projects are hidden/collapsed in the Issue/PR view
> > > > on expectations they are no longer 'interesting', requiring you to
> > > > spot that and expand the closed-projects view on each Issue/PR to see
> > > > the Project later. Which to be fair I think is actually decent
> > > > behaviour in general for their main use cases, since they aren't
> > > > really aimed to be used as versions but more for using the 'swimlane'
> > > > etc views given for managing/planning overall outstanding tasks to a
> > > > point of completion and will then most typically be
> > > > forgotten/less-interesting detail.
> > > >
> > > > On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> > > > <ch...@gmail.com> wrote:
> > > > >
> > > > > I am also on the Accumulo PMC and on that project we use Github
> > issues
> > > > > and no longer use Jira. This switch was made before my time so I'm
> > not
> > > > > sure of the reasoning. Personally, I don't really care too much
> > either
> > > > > way as I've used both but I will just point out 2 things from my
> > > > > experience with it.
> > > > >
> > > > > 1) For version tracking, we use projects and not milestones. I don't
> > > > > know if this is the best way to do things but that's what we have
> > been
> > > > > using and seems to work ok as you can list multiple projects
> > > > > (versions) for an Issue or PR:
> > > > > https://github.com/apache/accumulo/projects?type=classic
> > > > >
> > > > > 2) Robbie's point about whether or not Issues get opened is a really
> > > > > good point and something that is not consistent at all in Accumulo.
> > > > > What I have found is it is all over the place. In some cases people
> > > > > just open PRs and essentially are self documenting issues with the
> > > > > fix. In other cases people open up issues and then open up PRs. It
> > > > > does get confusing sometimes since they share the same numbering and
> > > > > name space. It may make sense to try and establish some guidelines if
> > > > > we go with Github Issues just so we are consistent about it.
> > > > >
> > > > > On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
> > > wrote:
> > > > > >
> > > > > >
> > > > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> > > robbie.gemmell@gmail.com> wrote:
> > > > > > >
> > > > > > > To the later point around Discussions, I do think enabling those
> > > could
> > > > > > > be good either way since, just like with Jira, people will often
> > > > > > > create Issues to ask questions rather than e.g mail a mailing
> > list.
> > > > > > > They might use a Discussion instead though.
> > > > > >
> > > > > > +1 agree that having discussions enabled would be an upgrade for
> > > users, big improvement over mailing lists.
> > > > > >
> > > > > > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
> > >
> > > wrote:
> > > > > > >>
> > > > > > >> There's been a few threads about this general subject, but most
> > > have
> > > > > > >> concentrated on Classic in particular. I think it's worth
> > > discussing
> > > > > > >> migration of ActiveMQ as a whole and diving a bit deeper into
> > the
> > > details
> > > > > > >> of why a migration makes (or doesn't make) sense and what the
> > > challenges
> > > > > > >> may be.
> > > > > > >>
> > > > > > >> To this end I've put together this document [1]. I hope it will
> > > be of
> > > > > > >> service to the community as we consider this option.
> > > > > > >>
> > > > > > >>
> > > > > > >> Justin
> > > > > > >>
> > > > > > >> [1]
> > > > > > >>
> > >
> > https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > > > > >
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> > >
> >

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi,

Thanks again Justin for the detailed doc, that's a great one !
I understand the gaps you identified and agree with your points.

Regarding the comments and feedback, I think we don't have a strong
enough consensus for this move.
So I would propose to stay with Jira for now.

Thoughts ?

Regards
JB

On Fri, Apr 5, 2024 at 6:47 PM Clebert Suconic
<cl...@gmail.com> wrote:
>
> Is there a private comment capability on GitHub?  To me that’s a breaking
> deal feature and I have never seen it.
>
> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> bruscinodf@gmail.com> wrote:
>
> > I don't have a strong opinion on migrating from Jira to GitHub Issues.
> > I would prefer GitHub Issues only for its better integration and because
> > new users that reach from the GitHub repository could be confused to not
> > find the `Issues` tabs (most of the GitHub projects use it).
> >
> > Also GitHub Issues has a good REST interface, I'm using it in
> > GithubIssueManager[1].
> >
> > @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
> >
> > [1]
> >
> > https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >
> > On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <cl...@gmail.com>
> > wrote:
> >
> > > I would prefer to keep JIRA for their REST interface.
> > >
> > > Also: one thing to notice is the possibility of using private comments
> > > in JIRA. Say you ever have a security issue. I think you can have PMC
> > > private comments on JIRAs. I'm not sure you have the same in github
> > > issues.
> > >
> > >
> > > I didn't see a note about private comments on Justin's detailed doc
> > > (nice Doc BTW), but the private comments may be handy on handling
> > > sensitive issues.
> > >
> > > On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <ro...@gmail.com>
> > > wrote:
> > > >
> > > > The 'track version as Project' thing is interesting, though kinda
> > > > further underscores the limitations of Milestones which are really the
> > > > main surfaced way of handling versions.
> > > >
> > > > I'll bet some folks on the 'users' side of things looking at released
> > > > issues later would even miss that you are doing that (I would), since
> > > > Projects are kinda separate and get even further hidden away upon
> > > > completion; closed Projects are hidden/collapsed in the Issue/PR view
> > > > on expectations they are no longer 'interesting', requiring you to
> > > > spot that and expand the closed-projects view on each Issue/PR to see
> > > > the Project later. Which to be fair I think is actually decent
> > > > behaviour in general for their main use cases, since they aren't
> > > > really aimed to be used as versions but more for using the 'swimlane'
> > > > etc views given for managing/planning overall outstanding tasks to a
> > > > point of completion and will then most typically be
> > > > forgotten/less-interesting detail.
> > > >
> > > > On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> > > > <ch...@gmail.com> wrote:
> > > > >
> > > > > I am also on the Accumulo PMC and on that project we use Github
> > issues
> > > > > and no longer use Jira. This switch was made before my time so I'm
> > not
> > > > > sure of the reasoning. Personally, I don't really care too much
> > either
> > > > > way as I've used both but I will just point out 2 things from my
> > > > > experience with it.
> > > > >
> > > > > 1) For version tracking, we use projects and not milestones. I don't
> > > > > know if this is the best way to do things but that's what we have
> > been
> > > > > using and seems to work ok as you can list multiple projects
> > > > > (versions) for an Issue or PR:
> > > > > https://github.com/apache/accumulo/projects?type=classic
> > > > >
> > > > > 2) Robbie's point about whether or not Issues get opened is a really
> > > > > good point and something that is not consistent at all in Accumulo.
> > > > > What I have found is it is all over the place. In some cases people
> > > > > just open PRs and essentially are self documenting issues with the
> > > > > fix. In other cases people open up issues and then open up PRs. It
> > > > > does get confusing sometimes since they share the same numbering and
> > > > > name space. It may make sense to try and establish some guidelines if
> > > > > we go with Github Issues just so we are consistent about it.
> > > > >
> > > > > On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
> > > wrote:
> > > > > >
> > > > > >
> > > > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> > > robbie.gemmell@gmail.com> wrote:
> > > > > > >
> > > > > > > To the later point around Discussions, I do think enabling those
> > > could
> > > > > > > be good either way since, just like with Jira, people will often
> > > > > > > create Issues to ask questions rather than e.g mail a mailing
> > list.
> > > > > > > They might use a Discussion instead though.
> > > > > >
> > > > > > +1 agree that having discussions enabled would be an upgrade for
> > > users, big improvement over mailing lists.
> > > > > >
> > > > > > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
> > >
> > > wrote:
> > > > > > >>
> > > > > > >> There's been a few threads about this general subject, but most
> > > have
> > > > > > >> concentrated on Classic in particular. I think it's worth
> > > discussing
> > > > > > >> migration of ActiveMQ as a whole and diving a bit deeper into
> > the
> > > details
> > > > > > >> of why a migration makes (or doesn't make) sense and what the
> > > challenges
> > > > > > >> may be.
> > > > > > >>
> > > > > > >> To this end I've put together this document [1]. I hope it will
> > > be of
> > > > > > >> service to the community as we consider this option.
> > > > > > >>
> > > > > > >>
> > > > > > >> Justin
> > > > > > >>
> > > > > > >> [1]
> > > > > > >>
> > >
> > https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > > > > >
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> > >
> >

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@gmail.com>]

Hi Bruce-

I don’t believe there is any intention to replace issue comments with comments on a PR or vice versa.

My point is that the current process of using JIRA for issue discussion isn’t really effective, and doesn’t serve a newer user base that is more familiar with using GitHub vs JIRA. A sizable chunk of discussion about fixes is happening on the PR’s today. Users filing a JIRA do not have the same visibility to the PR discussions there as they would vs if they filed a GH issue that is linked to a PR.

The JIRA <-> GH synchronization is wonky and spams the comments with the gitbox commits. With GH issues, the commit and PR work is listed in the issue history timeline, but that information set back and leads to an nicer (imho) navigation of the comments and track what is going on from a standard end-user POV (ie.. non-committer user).

Additionally, cross-project work is easier to reference because we can link across open source org repos for PRs and issues. Discussions flow and are referenced much smoother for collaborating with other projects such as Spring, Jetty, etc.

Taking the end-user approval workflow off the plate of the PMC is a side-benefit, but the main effect is lowering the barrier to entry for end-users and having a single account (with better transparency of identity) for issues and PR contributors. (GH account age, other GH project contributions, id verification, public keys, etc).

Today users in the ActiveMQ community need two accounts to report an issue and provide a PR. This doesn’t seem great to me.

In summary moving to GH issues is about:

1. Support for a single identity for issue and/or PR contribution
2. Use more familiar tools for a growing community of community users that are new to ActiveMQ
3. Centralize issue discussion and PR discussion
4. Remove JIRA user approval workflow from the plate of PMC
5. Possibly enabling discussion tools to provide better resource for users to interact with the ActiveMQ community in a more official capacity.

Thanks,
Matt

> On Apr 16, 2024, at 11:28 AM, Bruce Snyder <br...@gmail.com> wrote:
> 
> I am not convinced that we should replace Jira with Github issues. Based on
> the info gathered and the discussions thus far, I believe such a change
> would cause significant confusion for our users. As noted previously, there
> is a significant difference between the purposes for a Jira issue vs.
> comments in a PR. These are two completely different artifacts serving
> different needs in the process and you cannot replace one with the other.
> 
> Bruce
> 
> On Tue, Apr 16, 2024 at 9:27 AM Matt Pavlovich <ma...@gmail.com> wrote:
> 
>> @dev-
>> 
>> I’m summarizing the good points here and starting [PROPOSAL] thread to
>> draft up potential next steps.
>> 
>> Thanks,
>> Matt
>> 
>>> On Apr 16, 2024, at 9:58 AM, Matt Pavlovich <ma...@gmail.com> wrote:
>>> 
>>> Robbie-
>>> 
>>> One option with GH issues is we can have them prompted with a ’type’
>> (for example, an issue or security report). Security report workflow could
>> take them to the readme with email link to direct users to the mailing list
>> and (hopefully) getting better adherence to the requested security process.
>>> 
>>> -Matt
>>> 
>>>> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell <ro...@gmail.com>
>> wrote:
>>>> 
>>>> The security reporting/followup follow the process/requirements set
>>>> out by security@ so we cant really just change things around
>>>> that...though if there ideas, then perhaps they can be discussed with
>>>> them toward being generally applicable.
>>>> 
>>>> I believe there are private subversion repo areas for PMCs (never use
>>>> it though), not sure whether there are facilities yet for PMC git
>>>> repos.
>>>> 
>>>> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich <ma...@gmail.com> wrote:
>>>>> 
>>>>> Got it, that makes sense. I think we could achieve the same effect w/
>> a private repo (ie "activmeq-pmc”) and enable what ever product features
>> makes sense— issues, discussion, etc.
>>>>> 
>>>>> I agree, moving off of mailing list would be beneficial for certain
>> discussions (esp security reports) b/c of things like attachments, links,
>> etc often become a security challenge w/ email.
>>>>> 
>>>>> -Matt
>>>>> 
>>>>>> On Apr 5, 2024, at 6:58 PM, Clebert Suconic <
>> clebert.suconic@gmail.com> wrote:
>>>>>> 
>>>>>> I haven’t used it on the Apache Jira but I use private comments all
>> the
>>>>>> time on my company JIRA for things that would be related to security
>> and
>>>>>> injeritently private.
>>>>>> 
>>>>>> I thought we could eventually start using a feature like that and I
>> thought
>>>>>> it would be a nice feature to keep.  But if everybody think we should
>> keep
>>>>>> everything open and just use private list for private comments that’s
>> fine.
>>>>>> 
>>>>>> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com>
>> wrote:
>>>>>> 
>>>>>>> Hi Clebert-
>>>>>>> 
>>>>>>> How widely used are private comments today?
>>>>>>> 
>>>>>>> I ran a search and I do not see any private comments in use with the
>>>>>>> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I
>> got the
>>>>>>> JQL incorrect?
>>>>>>> 
>>>>>>> project = ARTEMIS AND issueFunction in commented("group
>> activemq-pmc”)
>>>>>>> project = ARTEMIS AND issueFunction in commented(“role PMC")
>>>>>>> 
>>>>>>> An available solution would be to use a private GH repo would secure
>> all
>>>>>>> the items — code, issues, etc.. from unprivileged users. A PMC-only
>> repo
>>>>>>> could have issues-only or discussion-only for CVE discussions.
>>>>>>> 
>>>>>>> I think private comment is a wonky concept, as it is easy to get that
>>>>>>> toggled incorrectly. I think it is better to restrict access to a
>> secured
>>>>>>> area vs trying to feather comments.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Matt
>>>>>>> 
>>>>>>>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <
>> clebert.suconic@gmail.com>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Is there a private comment capability on GitHub?  To me that’s a
>> breaking
>>>>>>>> deal feature and I have never seen it.
>>>>>>>> 
>>>>>>>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
>>>>>>>> bruscinodf@gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> I don't have a strong opinion on migrating from Jira to GitHub
>> Issues.
>>>>>>>>> I would prefer GitHub Issues only for its better integration and
>> because
>>>>>>>>> new users that reach from the GitHub repository could be confused
>> to not
>>>>>>>>> find the `Issues` tabs (most of the GitHub projects use it).
>>>>>>>>> 
>>>>>>>>> Also GitHub Issues has a good REST interface, I'm using it in
>>>>>>>>> GithubIssueManager[1].
>>>>>>>>> 
>>>>>>>>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
>>>>>>>>> 
>>>>>>>>> [1]
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
>>>>>>>>> 
>>>>>>>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <
>> clebert.suconic@gmail.com
>>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I would prefer to keep JIRA for their REST interface.
>>>>>>>>>> 
>>>>>>>>>> Also: one thing to notice is the possibility of using private
>> comments
>>>>>>>>>> in JIRA. Say you ever have a security issue. I think you can have
>> PMC
>>>>>>>>>> private comments on JIRAs. I'm not sure you have the same in
>> github
>>>>>>>>>> issues.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I didn't see a note about private comments on Justin's detailed
>> doc
>>>>>>>>>> (nice Doc BTW), but the private comments may be handy on handling
>>>>>>>>>> sensitive issues.
>>>>>>>>>> 
>>>>>>>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
>>>>>>> robbie.gemmell@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> The 'track version as Project' thing is interesting, though kinda
>>>>>>>>>>> further underscores the limitations of Milestones which are
>> really the
>>>>>>>>>>> main surfaced way of handling versions.
>>>>>>>>>>> 
>>>>>>>>>>> I'll bet some folks on the 'users' side of things looking at
>> released
>>>>>>>>>>> issues later would even miss that you are doing that (I would),
>> since
>>>>>>>>>>> Projects are kinda separate and get even further hidden away upon
>>>>>>>>>>> completion; closed Projects are hidden/collapsed in the Issue/PR
>> view
>>>>>>>>>>> on expectations they are no longer 'interesting', requiring you
>> to
>>>>>>>>>>> spot that and expand the closed-projects view on each Issue/PR
>> to see
>>>>>>>>>>> the Project later. Which to be fair I think is actually decent
>>>>>>>>>>> behaviour in general for their main use cases, since they aren't
>>>>>>>>>>> really aimed to be used as versions but more for using the
>> 'swimlane'
>>>>>>>>>>> etc views given for managing/planning overall outstanding tasks
>> to a
>>>>>>>>>>> point of completion and will then most typically be
>>>>>>>>>>> forgotten/less-interesting detail.
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
>>>>>>>>>>> <ch...@gmail.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I am also on the Accumulo PMC and on that project we use Github
>>>>>>>>> issues
>>>>>>>>>>>> and no longer use Jira. This switch was made before my time so
>> I'm
>>>>>>>>> not
>>>>>>>>>>>> sure of the reasoning. Personally, I don't really care too much
>>>>>>>>> either
>>>>>>>>>>>> way as I've used both but I will just point out 2 things from my
>>>>>>>>>>>> experience with it.
>>>>>>>>>>>> 
>>>>>>>>>>>> 1) For version tracking, we use projects and not milestones. I
>> don't
>>>>>>>>>>>> know if this is the best way to do things but that's what we
>> have
>>>>>>>>> been
>>>>>>>>>>>> using and seems to work ok as you can list multiple projects
>>>>>>>>>>>> (versions) for an Issue or PR:
>>>>>>>>>>>> https://github.com/apache/accumulo/projects?type=classic
>>>>>>>>>>>> 
>>>>>>>>>>>> 2) Robbie's point about whether or not Issues get opened is a
>> really
>>>>>>>>>>>> good point and something that is not consistent at all in
>> Accumulo.
>>>>>>>>>>>> What I have found is it is all over the place. In some cases
>> people
>>>>>>>>>>>> just open PRs and essentially are self documenting issues with
>> the
>>>>>>>>>>>> fix. In other cases people open up issues and then open up PRs.
>> It
>>>>>>>>>>>> does get confusing sometimes since they share the same
>> numbering and
>>>>>>>>>>>> name space. It may make sense to try and establish some
>> guidelines if
>>>>>>>>>>>> we go with Github Issues just so we are consistent about it.
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <
>> mattrpav@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
>>>>>>>>>> robbie.gemmell@gmail.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> To the later point around Discussions, I do think enabling
>> those
>>>>>>>>>> could
>>>>>>>>>>>>>> be good either way since, just like with Jira, people will
>> often
>>>>>>>>>>>>>> create Issues to ask questions rather than e.g mail a mailing
>>>>>>>>> list.
>>>>>>>>>>>>>> They might use a Discussion instead though.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1 agree that having discussions enabled would be an upgrade
>> for
>>>>>>>>>> users, big improvement over mailing lists.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <
>> jbertram@apache.org
>>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> There's been a few threads about this general subject, but
>> most
>>>>>>>>>> have
>>>>>>>>>>>>>>> concentrated on Classic in particular. I think it's worth
>>>>>>>>>> discussing
>>>>>>>>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
>>>>>>>>> the
>>>>>>>>>> details
>>>>>>>>>>>>>>> of why a migration makes (or doesn't make) sense and what the
>>>>>>>>>> challenges
>>>>>>>>>>>>>>> may be.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> To this end I've put together this document [1]. I hope it
>> will
>>>>>>>>>> be of
>>>>>>>>>>>>>>> service to the community as we consider this option.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Justin
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Clebert Suconic
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>> 
>> 
> 
> -- 
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );'
> http://bsnyder.org/ <http://bruceblog.org/>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Bruce Snyder <br...@gmail.com>]

I am not convinced that we should replace Jira with Github issues. Based on
the info gathered and the discussions thus far, I believe such a change
would cause significant confusion for our users. As noted previously, there
is a significant difference between the purposes for a Jira issue vs.
comments in a PR. These are two completely different artifacts serving
different needs in the process and you cannot replace one with the other.

Bruce

On Tue, Apr 16, 2024 at 9:27 AM Matt Pavlovich <ma...@gmail.com> wrote:

> @dev-
>
> I’m summarizing the good points here and starting [PROPOSAL] thread to
> draft up potential next steps.
>
> Thanks,
> Matt
>
> > On Apr 16, 2024, at 9:58 AM, Matt Pavlovich <ma...@gmail.com> wrote:
> >
> > Robbie-
> >
> > One option with GH issues is we can have them prompted with a ’type’
> (for example, an issue or security report). Security report workflow could
> take them to the readme with email link to direct users to the mailing list
> and (hopefully) getting better adherence to the requested security process.
> >
> > -Matt
> >
> >> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell <ro...@gmail.com>
> wrote:
> >>
> >> The security reporting/followup follow the process/requirements set
> >> out by security@ so we cant really just change things around
> >> that...though if there ideas, then perhaps they can be discussed with
> >> them toward being generally applicable.
> >>
> >> I believe there are private subversion repo areas for PMCs (never use
> >> it though), not sure whether there are facilities yet for PMC git
> >> repos.
> >>
> >> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich <ma...@gmail.com> wrote:
> >>>
> >>> Got it, that makes sense. I think we could achieve the same effect w/
> a private repo (ie "activmeq-pmc”) and enable what ever product features
> makes sense— issues, discussion, etc.
> >>>
> >>> I agree, moving off of mailing list would be beneficial for certain
> discussions (esp security reports) b/c of things like attachments, links,
> etc often become a security challenge w/ email.
> >>>
> >>> -Matt
> >>>
> >>>> On Apr 5, 2024, at 6:58 PM, Clebert Suconic <
> clebert.suconic@gmail.com> wrote:
> >>>>
> >>>> I haven’t used it on the Apache Jira but I use private comments all
> the
> >>>> time on my company JIRA for things that would be related to security
> and
> >>>> injeritently private.
> >>>>
> >>>> I thought we could eventually start using a feature like that and I
> thought
> >>>> it would be a nice feature to keep.  But if everybody think we should
> keep
> >>>> everything open and just use private list for private comments that’s
> fine.
> >>>>
> >>>> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com>
> wrote:
> >>>>
> >>>>> Hi Clebert-
> >>>>>
> >>>>> How widely used are private comments today?
> >>>>>
> >>>>> I ran a search and I do not see any private comments in use with the
> >>>>> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I
> got the
> >>>>> JQL incorrect?
> >>>>>
> >>>>> project = ARTEMIS AND issueFunction in commented("group
> activemq-pmc”)
> >>>>> project = ARTEMIS AND issueFunction in commented(“role PMC")
> >>>>>
> >>>>> An available solution would be to use a private GH repo would secure
> all
> >>>>> the items — code, issues, etc.. from unprivileged users. A PMC-only
> repo
> >>>>> could have issues-only or discussion-only for CVE discussions.
> >>>>>
> >>>>> I think private comment is a wonky concept, as it is easy to get that
> >>>>> toggled incorrectly. I think it is better to restrict access to a
> secured
> >>>>> area vs trying to feather comments.
> >>>>>
> >>>>> Thanks,
> >>>>> Matt
> >>>>>
> >>>>>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <
> clebert.suconic@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Is there a private comment capability on GitHub?  To me that’s a
> breaking
> >>>>>> deal feature and I have never seen it.
> >>>>>>
> >>>>>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> >>>>>> bruscinodf@gmail.com> wrote:
> >>>>>>
> >>>>>>> I don't have a strong opinion on migrating from Jira to GitHub
> Issues.
> >>>>>>> I would prefer GitHub Issues only for its better integration and
> because
> >>>>>>> new users that reach from the GitHub repository could be confused
> to not
> >>>>>>> find the `Issues` tabs (most of the GitHub projects use it).
> >>>>>>>
> >>>>>>> Also GitHub Issues has a good REST interface, I'm using it in
> >>>>>>> GithubIssueManager[1].
> >>>>>>>
> >>>>>>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> >>>>>>>
> >>>>>
> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >>>>>>>
> >>>>>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <
> clebert.suconic@gmail.com
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> I would prefer to keep JIRA for their REST interface.
> >>>>>>>>
> >>>>>>>> Also: one thing to notice is the possibility of using private
> comments
> >>>>>>>> in JIRA. Say you ever have a security issue. I think you can have
> PMC
> >>>>>>>> private comments on JIRAs. I'm not sure you have the same in
> github
> >>>>>>>> issues.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I didn't see a note about private comments on Justin's detailed
> doc
> >>>>>>>> (nice Doc BTW), but the private comments may be handy on handling
> >>>>>>>> sensitive issues.
> >>>>>>>>
> >>>>>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
> >>>>> robbie.gemmell@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> The 'track version as Project' thing is interesting, though kinda
> >>>>>>>>> further underscores the limitations of Milestones which are
> really the
> >>>>>>>>> main surfaced way of handling versions.
> >>>>>>>>>
> >>>>>>>>> I'll bet some folks on the 'users' side of things looking at
> released
> >>>>>>>>> issues later would even miss that you are doing that (I would),
> since
> >>>>>>>>> Projects are kinda separate and get even further hidden away upon
> >>>>>>>>> completion; closed Projects are hidden/collapsed in the Issue/PR
> view
> >>>>>>>>> on expectations they are no longer 'interesting', requiring you
> to
> >>>>>>>>> spot that and expand the closed-projects view on each Issue/PR
> to see
> >>>>>>>>> the Project later. Which to be fair I think is actually decent
> >>>>>>>>> behaviour in general for their main use cases, since they aren't
> >>>>>>>>> really aimed to be used as versions but more for using the
> 'swimlane'
> >>>>>>>>> etc views given for managing/planning overall outstanding tasks
> to a
> >>>>>>>>> point of completion and will then most typically be
> >>>>>>>>> forgotten/less-interesting detail.
> >>>>>>>>>
> >>>>>>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> >>>>>>>>> <ch...@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> I am also on the Accumulo PMC and on that project we use Github
> >>>>>>> issues
> >>>>>>>>>> and no longer use Jira. This switch was made before my time so
> I'm
> >>>>>>> not
> >>>>>>>>>> sure of the reasoning. Personally, I don't really care too much
> >>>>>>> either
> >>>>>>>>>> way as I've used both but I will just point out 2 things from my
> >>>>>>>>>> experience with it.
> >>>>>>>>>>
> >>>>>>>>>> 1) For version tracking, we use projects and not milestones. I
> don't
> >>>>>>>>>> know if this is the best way to do things but that's what we
> have
> >>>>>>> been
> >>>>>>>>>> using and seems to work ok as you can list multiple projects
> >>>>>>>>>> (versions) for an Issue or PR:
> >>>>>>>>>> https://github.com/apache/accumulo/projects?type=classic
> >>>>>>>>>>
> >>>>>>>>>> 2) Robbie's point about whether or not Issues get opened is a
> really
> >>>>>>>>>> good point and something that is not consistent at all in
> Accumulo.
> >>>>>>>>>> What I have found is it is all over the place. In some cases
> people
> >>>>>>>>>> just open PRs and essentially are self documenting issues with
> the
> >>>>>>>>>> fix. In other cases people open up issues and then open up PRs.
> It
> >>>>>>>>>> does get confusing sometimes since they share the same
> numbering and
> >>>>>>>>>> name space. It may make sense to try and establish some
> guidelines if
> >>>>>>>>>> we go with Github Issues just so we are consistent about it.
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <
> mattrpav@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> >>>>>>>> robbie.gemmell@gmail.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> To the later point around Discussions, I do think enabling
> those
> >>>>>>>> could
> >>>>>>>>>>>> be good either way since, just like with Jira, people will
> often
> >>>>>>>>>>>> create Issues to ask questions rather than e.g mail a mailing
> >>>>>>> list.
> >>>>>>>>>>>> They might use a Discussion instead though.
> >>>>>>>>>>>
> >>>>>>>>>>> +1 agree that having discussions enabled would be an upgrade
> for
> >>>>>>>> users, big improvement over mailing lists.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <
> jbertram@apache.org
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> There's been a few threads about this general subject, but
> most
> >>>>>>>> have
> >>>>>>>>>>>>> concentrated on Classic in particular. I think it's worth
> >>>>>>>> discussing
> >>>>>>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
> >>>>>>> the
> >>>>>>>> details
> >>>>>>>>>>>>> of why a migration makes (or doesn't make) sense and what the
> >>>>>>>> challenges
> >>>>>>>>>>>>> may be.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> To this end I've put together this document [1]. I hope it
> will
> >>>>>>>> be of
> >>>>>>>>>>>>> service to the community as we consider this option.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Justin
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Clebert Suconic
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >
>
>

-- 
perl -e 'print
unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );'
http://bsnyder.org/ <http://bruceblog.org/>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@gmail.com>]

Hi JB-

Yep, thanks for calling that out. When I indicated ‘security mailing list’ I should have been more clear to say ’security@apache.org’, to remove ambiguity that I was referring to an ActiveMQ mailing list.

I’ll clean-up points on the Proposal thread.

Thanks!
Matt

> On Apr 16, 2024, at 11:57 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 
> Hi Matt,
> 
> Thanks for that.
> 
> If I may, I don't see a strong consensus yet about GH Issues. The
> other thread you started contains some non accurate points (we should
> have clear statements to the community for clarity).
> 
> Regards
> JB
> 
> On Tue, Apr 16, 2024 at 5:26 PM Matt Pavlovich <ma...@gmail.com> wrote:
>> 
>> @dev-
>> 
>> I’m summarizing the good points here and starting [PROPOSAL] thread to draft up potential next steps.
>> 
>> Thanks,
>> Matt
>> 
>>> On Apr 16, 2024, at 9:58 AM, Matt Pavlovich <ma...@gmail.com> wrote:
>>> 
>>> Robbie-
>>> 
>>> One option with GH issues is we can have them prompted with a ’type’ (for example, an issue or security report). Security report workflow could take them to the readme with email link to direct users to the mailing list and (hopefully) getting better adherence to the requested security process.
>>> 
>>> -Matt
>>> 
>>>> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell <ro...@gmail.com> wrote:
>>>> 
>>>> The security reporting/followup follow the process/requirements set
>>>> out by security@ so we cant really just change things around
>>>> that...though if there ideas, then perhaps they can be discussed with
>>>> them toward being generally applicable.
>>>> 
>>>> I believe there are private subversion repo areas for PMCs (never use
>>>> it though), not sure whether there are facilities yet for PMC git
>>>> repos.
>>>> 
>>>> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich <ma...@gmail.com> wrote:
>>>>> 
>>>>> Got it, that makes sense. I think we could achieve the same effect w/ a private repo (ie "activmeq-pmc”) and enable what ever product features makes sense— issues, discussion, etc.
>>>>> 
>>>>> I agree, moving off of mailing list would be beneficial for certain discussions (esp security reports) b/c of things like attachments, links, etc often become a security challenge w/ email.
>>>>> 
>>>>> -Matt
>>>>> 
>>>>>> On Apr 5, 2024, at 6:58 PM, Clebert Suconic <cl...@gmail.com> wrote:
>>>>>> 
>>>>>> I haven’t used it on the Apache Jira but I use private comments all the
>>>>>> time on my company JIRA for things that would be related to security and
>>>>>> injeritently private.
>>>>>> 
>>>>>> I thought we could eventually start using a feature like that and I thought
>>>>>> it would be a nice feature to keep.  But if everybody think we should keep
>>>>>> everything open and just use private list for private comments that’s fine.
>>>>>> 
>>>>>> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com> wrote:
>>>>>> 
>>>>>>> Hi Clebert-
>>>>>>> 
>>>>>>> How widely used are private comments today?
>>>>>>> 
>>>>>>> I ran a search and I do not see any private comments in use with the
>>>>>>> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
>>>>>>> JQL incorrect?
>>>>>>> 
>>>>>>> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
>>>>>>> project = ARTEMIS AND issueFunction in commented(“role PMC")
>>>>>>> 
>>>>>>> An available solution would be to use a private GH repo would secure all
>>>>>>> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
>>>>>>> could have issues-only or discussion-only for CVE discussions.
>>>>>>> 
>>>>>>> I think private comment is a wonky concept, as it is easy to get that
>>>>>>> toggled incorrectly. I think it is better to restrict access to a secured
>>>>>>> area vs trying to feather comments.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Matt
>>>>>>> 
>>>>>>>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <cl...@gmail.com>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Is there a private comment capability on GitHub?  To me that’s a breaking
>>>>>>>> deal feature and I have never seen it.
>>>>>>>> 
>>>>>>>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
>>>>>>>> bruscinodf@gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> I don't have a strong opinion on migrating from Jira to GitHub Issues.
>>>>>>>>> I would prefer GitHub Issues only for its better integration and because
>>>>>>>>> new users that reach from the GitHub repository could be confused to not
>>>>>>>>> find the `Issues` tabs (most of the GitHub projects use it).
>>>>>>>>> 
>>>>>>>>> Also GitHub Issues has a good REST interface, I'm using it in
>>>>>>>>> GithubIssueManager[1].
>>>>>>>>> 
>>>>>>>>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
>>>>>>>>> 
>>>>>>>>> [1]
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
>>>>>>>>> 
>>>>>>>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suconic@gmail.com
>>>>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I would prefer to keep JIRA for their REST interface.
>>>>>>>>>> 
>>>>>>>>>> Also: one thing to notice is the possibility of using private comments
>>>>>>>>>> in JIRA. Say you ever have a security issue. I think you can have PMC
>>>>>>>>>> private comments on JIRAs. I'm not sure you have the same in github
>>>>>>>>>> issues.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I didn't see a note about private comments on Justin's detailed doc
>>>>>>>>>> (nice Doc BTW), but the private comments may be handy on handling
>>>>>>>>>> sensitive issues.
>>>>>>>>>> 
>>>>>>>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
>>>>>>> robbie.gemmell@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> The 'track version as Project' thing is interesting, though kinda
>>>>>>>>>>> further underscores the limitations of Milestones which are really the
>>>>>>>>>>> main surfaced way of handling versions.
>>>>>>>>>>> 
>>>>>>>>>>> I'll bet some folks on the 'users' side of things looking at released
>>>>>>>>>>> issues later would even miss that you are doing that (I would), since
>>>>>>>>>>> Projects are kinda separate and get even further hidden away upon
>>>>>>>>>>> completion; closed Projects are hidden/collapsed in the Issue/PR view
>>>>>>>>>>> on expectations they are no longer 'interesting', requiring you to
>>>>>>>>>>> spot that and expand the closed-projects view on each Issue/PR to see
>>>>>>>>>>> the Project later. Which to be fair I think is actually decent
>>>>>>>>>>> behaviour in general for their main use cases, since they aren't
>>>>>>>>>>> really aimed to be used as versions but more for using the 'swimlane'
>>>>>>>>>>> etc views given for managing/planning overall outstanding tasks to a
>>>>>>>>>>> point of completion and will then most typically be
>>>>>>>>>>> forgotten/less-interesting detail.
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
>>>>>>>>>>> <ch...@gmail.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I am also on the Accumulo PMC and on that project we use Github
>>>>>>>>> issues
>>>>>>>>>>>> and no longer use Jira. This switch was made before my time so I'm
>>>>>>>>> not
>>>>>>>>>>>> sure of the reasoning. Personally, I don't really care too much
>>>>>>>>> either
>>>>>>>>>>>> way as I've used both but I will just point out 2 things from my
>>>>>>>>>>>> experience with it.
>>>>>>>>>>>> 
>>>>>>>>>>>> 1) For version tracking, we use projects and not milestones. I don't
>>>>>>>>>>>> know if this is the best way to do things but that's what we have
>>>>>>>>> been
>>>>>>>>>>>> using and seems to work ok as you can list multiple projects
>>>>>>>>>>>> (versions) for an Issue or PR:
>>>>>>>>>>>> https://github.com/apache/accumulo/projects?type=classic
>>>>>>>>>>>> 
>>>>>>>>>>>> 2) Robbie's point about whether or not Issues get opened is a really
>>>>>>>>>>>> good point and something that is not consistent at all in Accumulo.
>>>>>>>>>>>> What I have found is it is all over the place. In some cases people
>>>>>>>>>>>> just open PRs and essentially are self documenting issues with the
>>>>>>>>>>>> fix. In other cases people open up issues and then open up PRs. It
>>>>>>>>>>>> does get confusing sometimes since they share the same numbering and
>>>>>>>>>>>> name space. It may make sense to try and establish some guidelines if
>>>>>>>>>>>> we go with Github Issues just so we are consistent about it.
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
>>>>>>>>>> robbie.gemmell@gmail.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> To the later point around Discussions, I do think enabling those
>>>>>>>>>> could
>>>>>>>>>>>>>> be good either way since, just like with Jira, people will often
>>>>>>>>>>>>>> create Issues to ask questions rather than e.g mail a mailing
>>>>>>>>> list.
>>>>>>>>>>>>>> They might use a Discussion instead though.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> +1 agree that having discussions enabled would be an upgrade for
>>>>>>>>>> users, big improvement over mailing lists.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
>>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> There's been a few threads about this general subject, but most
>>>>>>>>>> have
>>>>>>>>>>>>>>> concentrated on Classic in particular. I think it's worth
>>>>>>>>>> discussing
>>>>>>>>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
>>>>>>>>> the
>>>>>>>>>> details
>>>>>>>>>>>>>>> of why a migration makes (or doesn't make) sense and what the
>>>>>>>>>> challenges
>>>>>>>>>>>>>>> may be.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> To this end I've put together this document [1]. I hope it will
>>>>>>>>>> be of
>>>>>>>>>>>>>>> service to the community as we consider this option.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Justin
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Clebert Suconic
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>> 

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Matt,

Thanks for that.

If I may, I don't see a strong consensus yet about GH Issues. The
other thread you started contains some non accurate points (we should
have clear statements to the community for clarity).

Regards
JB

On Tue, Apr 16, 2024 at 5:26 PM Matt Pavlovich <ma...@gmail.com> wrote:
>
> @dev-
>
> I’m summarizing the good points here and starting [PROPOSAL] thread to draft up potential next steps.
>
> Thanks,
> Matt
>
> > On Apr 16, 2024, at 9:58 AM, Matt Pavlovich <ma...@gmail.com> wrote:
> >
> > Robbie-
> >
> > One option with GH issues is we can have them prompted with a ’type’ (for example, an issue or security report). Security report workflow could take them to the readme with email link to direct users to the mailing list and (hopefully) getting better adherence to the requested security process.
> >
> > -Matt
> >
> >> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell <ro...@gmail.com> wrote:
> >>
> >> The security reporting/followup follow the process/requirements set
> >> out by security@ so we cant really just change things around
> >> that...though if there ideas, then perhaps they can be discussed with
> >> them toward being generally applicable.
> >>
> >> I believe there are private subversion repo areas for PMCs (never use
> >> it though), not sure whether there are facilities yet for PMC git
> >> repos.
> >>
> >> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich <ma...@gmail.com> wrote:
> >>>
> >>> Got it, that makes sense. I think we could achieve the same effect w/ a private repo (ie "activmeq-pmc”) and enable what ever product features makes sense— issues, discussion, etc.
> >>>
> >>> I agree, moving off of mailing list would be beneficial for certain discussions (esp security reports) b/c of things like attachments, links, etc often become a security challenge w/ email.
> >>>
> >>> -Matt
> >>>
> >>>> On Apr 5, 2024, at 6:58 PM, Clebert Suconic <cl...@gmail.com> wrote:
> >>>>
> >>>> I haven’t used it on the Apache Jira but I use private comments all the
> >>>> time on my company JIRA for things that would be related to security and
> >>>> injeritently private.
> >>>>
> >>>> I thought we could eventually start using a feature like that and I thought
> >>>> it would be a nice feature to keep.  But if everybody think we should keep
> >>>> everything open and just use private list for private comments that’s fine.
> >>>>
> >>>> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com> wrote:
> >>>>
> >>>>> Hi Clebert-
> >>>>>
> >>>>> How widely used are private comments today?
> >>>>>
> >>>>> I ran a search and I do not see any private comments in use with the
> >>>>> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
> >>>>> JQL incorrect?
> >>>>>
> >>>>> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> >>>>> project = ARTEMIS AND issueFunction in commented(“role PMC")
> >>>>>
> >>>>> An available solution would be to use a private GH repo would secure all
> >>>>> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> >>>>> could have issues-only or discussion-only for CVE discussions.
> >>>>>
> >>>>> I think private comment is a wonky concept, as it is easy to get that
> >>>>> toggled incorrectly. I think it is better to restrict access to a secured
> >>>>> area vs trying to feather comments.
> >>>>>
> >>>>> Thanks,
> >>>>> Matt
> >>>>>
> >>>>>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <cl...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Is there a private comment capability on GitHub?  To me that’s a breaking
> >>>>>> deal feature and I have never seen it.
> >>>>>>
> >>>>>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> >>>>>> bruscinodf@gmail.com> wrote:
> >>>>>>
> >>>>>>> I don't have a strong opinion on migrating from Jira to GitHub Issues.
> >>>>>>> I would prefer GitHub Issues only for its better integration and because
> >>>>>>> new users that reach from the GitHub repository could be confused to not
> >>>>>>> find the `Issues` tabs (most of the GitHub projects use it).
> >>>>>>>
> >>>>>>> Also GitHub Issues has a good REST interface, I'm using it in
> >>>>>>> GithubIssueManager[1].
> >>>>>>>
> >>>>>>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> >>>>>>>
> >>>>> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >>>>>>>
> >>>>>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suconic@gmail.com
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> I would prefer to keep JIRA for their REST interface.
> >>>>>>>>
> >>>>>>>> Also: one thing to notice is the possibility of using private comments
> >>>>>>>> in JIRA. Say you ever have a security issue. I think you can have PMC
> >>>>>>>> private comments on JIRAs. I'm not sure you have the same in github
> >>>>>>>> issues.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I didn't see a note about private comments on Justin's detailed doc
> >>>>>>>> (nice Doc BTW), but the private comments may be handy on handling
> >>>>>>>> sensitive issues.
> >>>>>>>>
> >>>>>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
> >>>>> robbie.gemmell@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> The 'track version as Project' thing is interesting, though kinda
> >>>>>>>>> further underscores the limitations of Milestones which are really the
> >>>>>>>>> main surfaced way of handling versions.
> >>>>>>>>>
> >>>>>>>>> I'll bet some folks on the 'users' side of things looking at released
> >>>>>>>>> issues later would even miss that you are doing that (I would), since
> >>>>>>>>> Projects are kinda separate and get even further hidden away upon
> >>>>>>>>> completion; closed Projects are hidden/collapsed in the Issue/PR view
> >>>>>>>>> on expectations they are no longer 'interesting', requiring you to
> >>>>>>>>> spot that and expand the closed-projects view on each Issue/PR to see
> >>>>>>>>> the Project later. Which to be fair I think is actually decent
> >>>>>>>>> behaviour in general for their main use cases, since they aren't
> >>>>>>>>> really aimed to be used as versions but more for using the 'swimlane'
> >>>>>>>>> etc views given for managing/planning overall outstanding tasks to a
> >>>>>>>>> point of completion and will then most typically be
> >>>>>>>>> forgotten/less-interesting detail.
> >>>>>>>>>
> >>>>>>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> >>>>>>>>> <ch...@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> I am also on the Accumulo PMC and on that project we use Github
> >>>>>>> issues
> >>>>>>>>>> and no longer use Jira. This switch was made before my time so I'm
> >>>>>>> not
> >>>>>>>>>> sure of the reasoning. Personally, I don't really care too much
> >>>>>>> either
> >>>>>>>>>> way as I've used both but I will just point out 2 things from my
> >>>>>>>>>> experience with it.
> >>>>>>>>>>
> >>>>>>>>>> 1) For version tracking, we use projects and not milestones. I don't
> >>>>>>>>>> know if this is the best way to do things but that's what we have
> >>>>>>> been
> >>>>>>>>>> using and seems to work ok as you can list multiple projects
> >>>>>>>>>> (versions) for an Issue or PR:
> >>>>>>>>>> https://github.com/apache/accumulo/projects?type=classic
> >>>>>>>>>>
> >>>>>>>>>> 2) Robbie's point about whether or not Issues get opened is a really
> >>>>>>>>>> good point and something that is not consistent at all in Accumulo.
> >>>>>>>>>> What I have found is it is all over the place. In some cases people
> >>>>>>>>>> just open PRs and essentially are self documenting issues with the
> >>>>>>>>>> fix. In other cases people open up issues and then open up PRs. It
> >>>>>>>>>> does get confusing sometimes since they share the same numbering and
> >>>>>>>>>> name space. It may make sense to try and establish some guidelines if
> >>>>>>>>>> we go with Github Issues just so we are consistent about it.
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> >>>>>>>> robbie.gemmell@gmail.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> To the later point around Discussions, I do think enabling those
> >>>>>>>> could
> >>>>>>>>>>>> be good either way since, just like with Jira, people will often
> >>>>>>>>>>>> create Issues to ask questions rather than e.g mail a mailing
> >>>>>>> list.
> >>>>>>>>>>>> They might use a Discussion instead though.
> >>>>>>>>>>>
> >>>>>>>>>>> +1 agree that having discussions enabled would be an upgrade for
> >>>>>>>> users, big improvement over mailing lists.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> There's been a few threads about this general subject, but most
> >>>>>>>> have
> >>>>>>>>>>>>> concentrated on Classic in particular. I think it's worth
> >>>>>>>> discussing
> >>>>>>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
> >>>>>>> the
> >>>>>>>> details
> >>>>>>>>>>>>> of why a migration makes (or doesn't make) sense and what the
> >>>>>>>> challenges
> >>>>>>>>>>>>> may be.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> To this end I've put together this document [1]. I hope it will
> >>>>>>>> be of
> >>>>>>>>>>>>> service to the community as we consider this option.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Justin
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Clebert Suconic
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@gmail.com>]

@dev-

I’m summarizing the good points here and starting [PROPOSAL] thread to draft up potential next steps.

Thanks,
Matt

> On Apr 16, 2024, at 9:58 AM, Matt Pavlovich <ma...@gmail.com> wrote:
> 
> Robbie-
> 
> One option with GH issues is we can have them prompted with a ’type’ (for example, an issue or security report). Security report workflow could take them to the readme with email link to direct users to the mailing list and (hopefully) getting better adherence to the requested security process.
> 
> -Matt
> 
>> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell <ro...@gmail.com> wrote:
>> 
>> The security reporting/followup follow the process/requirements set
>> out by security@ so we cant really just change things around
>> that...though if there ideas, then perhaps they can be discussed with
>> them toward being generally applicable.
>> 
>> I believe there are private subversion repo areas for PMCs (never use
>> it though), not sure whether there are facilities yet for PMC git
>> repos.
>> 
>> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich <ma...@gmail.com> wrote:
>>> 
>>> Got it, that makes sense. I think we could achieve the same effect w/ a private repo (ie "activmeq-pmc”) and enable what ever product features makes sense— issues, discussion, etc.
>>> 
>>> I agree, moving off of mailing list would be beneficial for certain discussions (esp security reports) b/c of things like attachments, links, etc often become a security challenge w/ email.
>>> 
>>> -Matt
>>> 
>>>> On Apr 5, 2024, at 6:58 PM, Clebert Suconic <cl...@gmail.com> wrote:
>>>> 
>>>> I haven’t used it on the Apache Jira but I use private comments all the
>>>> time on my company JIRA for things that would be related to security and
>>>> injeritently private.
>>>> 
>>>> I thought we could eventually start using a feature like that and I thought
>>>> it would be a nice feature to keep.  But if everybody think we should keep
>>>> everything open and just use private list for private comments that’s fine.
>>>> 
>>>> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com> wrote:
>>>> 
>>>>> Hi Clebert-
>>>>> 
>>>>> How widely used are private comments today?
>>>>> 
>>>>> I ran a search and I do not see any private comments in use with the
>>>>> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
>>>>> JQL incorrect?
>>>>> 
>>>>> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
>>>>> project = ARTEMIS AND issueFunction in commented(“role PMC")
>>>>> 
>>>>> An available solution would be to use a private GH repo would secure all
>>>>> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
>>>>> could have issues-only or discussion-only for CVE discussions.
>>>>> 
>>>>> I think private comment is a wonky concept, as it is easy to get that
>>>>> toggled incorrectly. I think it is better to restrict access to a secured
>>>>> area vs trying to feather comments.
>>>>> 
>>>>> Thanks,
>>>>> Matt
>>>>> 
>>>>>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <cl...@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>> Is there a private comment capability on GitHub?  To me that’s a breaking
>>>>>> deal feature and I have never seen it.
>>>>>> 
>>>>>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
>>>>>> bruscinodf@gmail.com> wrote:
>>>>>> 
>>>>>>> I don't have a strong opinion on migrating from Jira to GitHub Issues.
>>>>>>> I would prefer GitHub Issues only for its better integration and because
>>>>>>> new users that reach from the GitHub repository could be confused to not
>>>>>>> find the `Issues` tabs (most of the GitHub projects use it).
>>>>>>> 
>>>>>>> Also GitHub Issues has a good REST interface, I'm using it in
>>>>>>> GithubIssueManager[1].
>>>>>>> 
>>>>>>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
>>>>>>> 
>>>>>>> [1]
>>>>>>> 
>>>>>>> 
>>>>> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
>>>>>>> 
>>>>>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suconic@gmail.com
>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> I would prefer to keep JIRA for their REST interface.
>>>>>>>> 
>>>>>>>> Also: one thing to notice is the possibility of using private comments
>>>>>>>> in JIRA. Say you ever have a security issue. I think you can have PMC
>>>>>>>> private comments on JIRAs. I'm not sure you have the same in github
>>>>>>>> issues.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I didn't see a note about private comments on Justin's detailed doc
>>>>>>>> (nice Doc BTW), but the private comments may be handy on handling
>>>>>>>> sensitive issues.
>>>>>>>> 
>>>>>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
>>>>> robbie.gemmell@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> The 'track version as Project' thing is interesting, though kinda
>>>>>>>>> further underscores the limitations of Milestones which are really the
>>>>>>>>> main surfaced way of handling versions.
>>>>>>>>> 
>>>>>>>>> I'll bet some folks on the 'users' side of things looking at released
>>>>>>>>> issues later would even miss that you are doing that (I would), since
>>>>>>>>> Projects are kinda separate and get even further hidden away upon
>>>>>>>>> completion; closed Projects are hidden/collapsed in the Issue/PR view
>>>>>>>>> on expectations they are no longer 'interesting', requiring you to
>>>>>>>>> spot that and expand the closed-projects view on each Issue/PR to see
>>>>>>>>> the Project later. Which to be fair I think is actually decent
>>>>>>>>> behaviour in general for their main use cases, since they aren't
>>>>>>>>> really aimed to be used as versions but more for using the 'swimlane'
>>>>>>>>> etc views given for managing/planning overall outstanding tasks to a
>>>>>>>>> point of completion and will then most typically be
>>>>>>>>> forgotten/less-interesting detail.
>>>>>>>>> 
>>>>>>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
>>>>>>>>> <ch...@gmail.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> I am also on the Accumulo PMC and on that project we use Github
>>>>>>> issues
>>>>>>>>>> and no longer use Jira. This switch was made before my time so I'm
>>>>>>> not
>>>>>>>>>> sure of the reasoning. Personally, I don't really care too much
>>>>>>> either
>>>>>>>>>> way as I've used both but I will just point out 2 things from my
>>>>>>>>>> experience with it.
>>>>>>>>>> 
>>>>>>>>>> 1) For version tracking, we use projects and not milestones. I don't
>>>>>>>>>> know if this is the best way to do things but that's what we have
>>>>>>> been
>>>>>>>>>> using and seems to work ok as you can list multiple projects
>>>>>>>>>> (versions) for an Issue or PR:
>>>>>>>>>> https://github.com/apache/accumulo/projects?type=classic
>>>>>>>>>> 
>>>>>>>>>> 2) Robbie's point about whether or not Issues get opened is a really
>>>>>>>>>> good point and something that is not consistent at all in Accumulo.
>>>>>>>>>> What I have found is it is all over the place. In some cases people
>>>>>>>>>> just open PRs and essentially are self documenting issues with the
>>>>>>>>>> fix. In other cases people open up issues and then open up PRs. It
>>>>>>>>>> does get confusing sometimes since they share the same numbering and
>>>>>>>>>> name space. It may make sense to try and establish some guidelines if
>>>>>>>>>> we go with Github Issues just so we are consistent about it.
>>>>>>>>>> 
>>>>>>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
>>>>>>>> robbie.gemmell@gmail.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> To the later point around Discussions, I do think enabling those
>>>>>>>> could
>>>>>>>>>>>> be good either way since, just like with Jira, people will often
>>>>>>>>>>>> create Issues to ask questions rather than e.g mail a mailing
>>>>>>> list.
>>>>>>>>>>>> They might use a Discussion instead though.
>>>>>>>>>>> 
>>>>>>>>>>> +1 agree that having discussions enabled would be an upgrade for
>>>>>>>> users, big improvement over mailing lists.
>>>>>>>>>>> 
>>>>>>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> There's been a few threads about this general subject, but most
>>>>>>>> have
>>>>>>>>>>>>> concentrated on Classic in particular. I think it's worth
>>>>>>>> discussing
>>>>>>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
>>>>>>> the
>>>>>>>> details
>>>>>>>>>>>>> of why a migration makes (or doesn't make) sense and what the
>>>>>>>> challenges
>>>>>>>>>>>>> may be.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> To this end I've put together this document [1]. I hope it will
>>>>>>>> be of
>>>>>>>>>>>>> service to the community as we consider this option.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Justin
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Clebert Suconic
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
> 

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@gmail.com>]

Robbie-

One option with GH issues is we can have them prompted with a ’type’ (for example, an issue or security report). Security report workflow could take them to the readme with email link to direct users to the mailing list and (hopefully) getting better adherence to the requested security process.

-Matt

> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell <ro...@gmail.com> wrote:
> 
> The security reporting/followup follow the process/requirements set
> out by security@ so we cant really just change things around
> that...though if there ideas, then perhaps they can be discussed with
> them toward being generally applicable.
> 
> I believe there are private subversion repo areas for PMCs (never use
> it though), not sure whether there are facilities yet for PMC git
> repos.
> 
> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich <ma...@gmail.com> wrote:
>> 
>> Got it, that makes sense. I think we could achieve the same effect w/ a private repo (ie "activmeq-pmc”) and enable what ever product features makes sense— issues, discussion, etc.
>> 
>> I agree, moving off of mailing list would be beneficial for certain discussions (esp security reports) b/c of things like attachments, links, etc often become a security challenge w/ email.
>> 
>> -Matt
>> 
>>> On Apr 5, 2024, at 6:58 PM, Clebert Suconic <cl...@gmail.com> wrote:
>>> 
>>> I haven’t used it on the Apache Jira but I use private comments all the
>>> time on my company JIRA for things that would be related to security and
>>> injeritently private.
>>> 
>>> I thought we could eventually start using a feature like that and I thought
>>> it would be a nice feature to keep.  But if everybody think we should keep
>>> everything open and just use private list for private comments that’s fine.
>>> 
>>> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com> wrote:
>>> 
>>>> Hi Clebert-
>>>> 
>>>> How widely used are private comments today?
>>>> 
>>>> I ran a search and I do not see any private comments in use with the
>>>> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
>>>> JQL incorrect?
>>>> 
>>>> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
>>>> project = ARTEMIS AND issueFunction in commented(“role PMC")
>>>> 
>>>> An available solution would be to use a private GH repo would secure all
>>>> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
>>>> could have issues-only or discussion-only for CVE discussions.
>>>> 
>>>> I think private comment is a wonky concept, as it is easy to get that
>>>> toggled incorrectly. I think it is better to restrict access to a secured
>>>> area vs trying to feather comments.
>>>> 
>>>> Thanks,
>>>> Matt
>>>> 
>>>>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <cl...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> Is there a private comment capability on GitHub?  To me that’s a breaking
>>>>> deal feature and I have never seen it.
>>>>> 
>>>>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
>>>>> bruscinodf@gmail.com> wrote:
>>>>> 
>>>>>> I don't have a strong opinion on migrating from Jira to GitHub Issues.
>>>>>> I would prefer GitHub Issues only for its better integration and because
>>>>>> new users that reach from the GitHub repository could be confused to not
>>>>>> find the `Issues` tabs (most of the GitHub projects use it).
>>>>>> 
>>>>>> Also GitHub Issues has a good REST interface, I'm using it in
>>>>>> GithubIssueManager[1].
>>>>>> 
>>>>>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
>>>>>> 
>>>>>> [1]
>>>>>> 
>>>>>> 
>>>> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
>>>>>> 
>>>>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suconic@gmail.com
>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> I would prefer to keep JIRA for their REST interface.
>>>>>>> 
>>>>>>> Also: one thing to notice is the possibility of using private comments
>>>>>>> in JIRA. Say you ever have a security issue. I think you can have PMC
>>>>>>> private comments on JIRAs. I'm not sure you have the same in github
>>>>>>> issues.
>>>>>>> 
>>>>>>> 
>>>>>>> I didn't see a note about private comments on Justin's detailed doc
>>>>>>> (nice Doc BTW), but the private comments may be handy on handling
>>>>>>> sensitive issues.
>>>>>>> 
>>>>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
>>>> robbie.gemmell@gmail.com>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> The 'track version as Project' thing is interesting, though kinda
>>>>>>>> further underscores the limitations of Milestones which are really the
>>>>>>>> main surfaced way of handling versions.
>>>>>>>> 
>>>>>>>> I'll bet some folks on the 'users' side of things looking at released
>>>>>>>> issues later would even miss that you are doing that (I would), since
>>>>>>>> Projects are kinda separate and get even further hidden away upon
>>>>>>>> completion; closed Projects are hidden/collapsed in the Issue/PR view
>>>>>>>> on expectations they are no longer 'interesting', requiring you to
>>>>>>>> spot that and expand the closed-projects view on each Issue/PR to see
>>>>>>>> the Project later. Which to be fair I think is actually decent
>>>>>>>> behaviour in general for their main use cases, since they aren't
>>>>>>>> really aimed to be used as versions but more for using the 'swimlane'
>>>>>>>> etc views given for managing/planning overall outstanding tasks to a
>>>>>>>> point of completion and will then most typically be
>>>>>>>> forgotten/less-interesting detail.
>>>>>>>> 
>>>>>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
>>>>>>>> <ch...@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> I am also on the Accumulo PMC and on that project we use Github
>>>>>> issues
>>>>>>>>> and no longer use Jira. This switch was made before my time so I'm
>>>>>> not
>>>>>>>>> sure of the reasoning. Personally, I don't really care too much
>>>>>> either
>>>>>>>>> way as I've used both but I will just point out 2 things from my
>>>>>>>>> experience with it.
>>>>>>>>> 
>>>>>>>>> 1) For version tracking, we use projects and not milestones. I don't
>>>>>>>>> know if this is the best way to do things but that's what we have
>>>>>> been
>>>>>>>>> using and seems to work ok as you can list multiple projects
>>>>>>>>> (versions) for an Issue or PR:
>>>>>>>>> https://github.com/apache/accumulo/projects?type=classic
>>>>>>>>> 
>>>>>>>>> 2) Robbie's point about whether or not Issues get opened is a really
>>>>>>>>> good point and something that is not consistent at all in Accumulo.
>>>>>>>>> What I have found is it is all over the place. In some cases people
>>>>>>>>> just open PRs and essentially are self documenting issues with the
>>>>>>>>> fix. In other cases people open up issues and then open up PRs. It
>>>>>>>>> does get confusing sometimes since they share the same numbering and
>>>>>>>>> name space. It may make sense to try and establish some guidelines if
>>>>>>>>> we go with Github Issues just so we are consistent about it.
>>>>>>>>> 
>>>>>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
>>>>>>> robbie.gemmell@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> To the later point around Discussions, I do think enabling those
>>>>>>> could
>>>>>>>>>>> be good either way since, just like with Jira, people will often
>>>>>>>>>>> create Issues to ask questions rather than e.g mail a mailing
>>>>>> list.
>>>>>>>>>>> They might use a Discussion instead though.
>>>>>>>>>> 
>>>>>>>>>> +1 agree that having discussions enabled would be an upgrade for
>>>>>>> users, big improvement over mailing lists.
>>>>>>>>>> 
>>>>>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
>>>>>>> 
>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> There's been a few threads about this general subject, but most
>>>>>>> have
>>>>>>>>>>>> concentrated on Classic in particular. I think it's worth
>>>>>>> discussing
>>>>>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
>>>>>> the
>>>>>>> details
>>>>>>>>>>>> of why a migration makes (or doesn't make) sense and what the
>>>>>>> challenges
>>>>>>>>>>>> may be.
>>>>>>>>>>>> 
>>>>>>>>>>>> To this end I've put together this document [1]. I hope it will
>>>>>>> be of
>>>>>>>>>>>> service to the community as we consider this option.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Justin
>>>>>>>>>>>> 
>>>>>>>>>>>> [1]
>>>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Clebert Suconic
>>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell <ro...@gmail.com>]

The security reporting/followup follow the process/requirements set
out by security@ so we cant really just change things around
that...though if there ideas, then perhaps they can be discussed with
them toward being generally applicable.

I believe there are private subversion repo areas for PMCs (never use
it though), not sure whether there are facilities yet for PMC git
repos.

On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich <ma...@gmail.com> wrote:
>
> Got it, that makes sense. I think we could achieve the same effect w/ a private repo (ie "activmeq-pmc”) and enable what ever product features makes sense— issues, discussion, etc.
>
> I agree, moving off of mailing list would be beneficial for certain discussions (esp security reports) b/c of things like attachments, links, etc often become a security challenge w/ email.
>
> -Matt
>
> > On Apr 5, 2024, at 6:58 PM, Clebert Suconic <cl...@gmail.com> wrote:
> >
> > I haven’t used it on the Apache Jira but I use private comments all the
> > time on my company JIRA for things that would be related to security and
> > injeritently private.
> >
> > I thought we could eventually start using a feature like that and I thought
> > it would be a nice feature to keep.  But if everybody think we should keep
> > everything open and just use private list for private comments that’s fine.
> >
> > On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com> wrote:
> >
> >> Hi Clebert-
> >>
> >> How widely used are private comments today?
> >>
> >> I ran a search and I do not see any private comments in use with the
> >> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
> >> JQL incorrect?
> >>
> >> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> >> project = ARTEMIS AND issueFunction in commented(“role PMC")
> >>
> >> An available solution would be to use a private GH repo would secure all
> >> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> >> could have issues-only or discussion-only for CVE discussions.
> >>
> >> I think private comment is a wonky concept, as it is easy to get that
> >> toggled incorrectly. I think it is better to restrict access to a secured
> >> area vs trying to feather comments.
> >>
> >> Thanks,
> >> Matt
> >>
> >>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <cl...@gmail.com>
> >> wrote:
> >>>
> >>> Is there a private comment capability on GitHub?  To me that’s a breaking
> >>> deal feature and I have never seen it.
> >>>
> >>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> >>> bruscinodf@gmail.com> wrote:
> >>>
> >>>> I don't have a strong opinion on migrating from Jira to GitHub Issues.
> >>>> I would prefer GitHub Issues only for its better integration and because
> >>>> new users that reach from the GitHub repository could be confused to not
> >>>> find the `Issues` tabs (most of the GitHub projects use it).
> >>>>
> >>>> Also GitHub Issues has a good REST interface, I'm using it in
> >>>> GithubIssueManager[1].
> >>>>
> >>>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >>>>
> >>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suconic@gmail.com
> >>>
> >>>> wrote:
> >>>>
> >>>>> I would prefer to keep JIRA for their REST interface.
> >>>>>
> >>>>> Also: one thing to notice is the possibility of using private comments
> >>>>> in JIRA. Say you ever have a security issue. I think you can have PMC
> >>>>> private comments on JIRAs. I'm not sure you have the same in github
> >>>>> issues.
> >>>>>
> >>>>>
> >>>>> I didn't see a note about private comments on Justin's detailed doc
> >>>>> (nice Doc BTW), but the private comments may be handy on handling
> >>>>> sensitive issues.
> >>>>>
> >>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
> >> robbie.gemmell@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> The 'track version as Project' thing is interesting, though kinda
> >>>>>> further underscores the limitations of Milestones which are really the
> >>>>>> main surfaced way of handling versions.
> >>>>>>
> >>>>>> I'll bet some folks on the 'users' side of things looking at released
> >>>>>> issues later would even miss that you are doing that (I would), since
> >>>>>> Projects are kinda separate and get even further hidden away upon
> >>>>>> completion; closed Projects are hidden/collapsed in the Issue/PR view
> >>>>>> on expectations they are no longer 'interesting', requiring you to
> >>>>>> spot that and expand the closed-projects view on each Issue/PR to see
> >>>>>> the Project later. Which to be fair I think is actually decent
> >>>>>> behaviour in general for their main use cases, since they aren't
> >>>>>> really aimed to be used as versions but more for using the 'swimlane'
> >>>>>> etc views given for managing/planning overall outstanding tasks to a
> >>>>>> point of completion and will then most typically be
> >>>>>> forgotten/less-interesting detail.
> >>>>>>
> >>>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> >>>>>> <ch...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> I am also on the Accumulo PMC and on that project we use Github
> >>>> issues
> >>>>>>> and no longer use Jira. This switch was made before my time so I'm
> >>>> not
> >>>>>>> sure of the reasoning. Personally, I don't really care too much
> >>>> either
> >>>>>>> way as I've used both but I will just point out 2 things from my
> >>>>>>> experience with it.
> >>>>>>>
> >>>>>>> 1) For version tracking, we use projects and not milestones. I don't
> >>>>>>> know if this is the best way to do things but that's what we have
> >>>> been
> >>>>>>> using and seems to work ok as you can list multiple projects
> >>>>>>> (versions) for an Issue or PR:
> >>>>>>> https://github.com/apache/accumulo/projects?type=classic
> >>>>>>>
> >>>>>>> 2) Robbie's point about whether or not Issues get opened is a really
> >>>>>>> good point and something that is not consistent at all in Accumulo.
> >>>>>>> What I have found is it is all over the place. In some cases people
> >>>>>>> just open PRs and essentially are self documenting issues with the
> >>>>>>> fix. In other cases people open up issues and then open up PRs. It
> >>>>>>> does get confusing sometimes since they share the same numbering and
> >>>>>>> name space. It may make sense to try and establish some guidelines if
> >>>>>>> we go with Github Issues just so we are consistent about it.
> >>>>>>>
> >>>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> >>>>> robbie.gemmell@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> To the later point around Discussions, I do think enabling those
> >>>>> could
> >>>>>>>>> be good either way since, just like with Jira, people will often
> >>>>>>>>> create Issues to ask questions rather than e.g mail a mailing
> >>>> list.
> >>>>>>>>> They might use a Discussion instead though.
> >>>>>>>>
> >>>>>>>> +1 agree that having discussions enabled would be an upgrade for
> >>>>> users, big improvement over mailing lists.
> >>>>>>>>
> >>>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
> >>>>>
> >>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> There's been a few threads about this general subject, but most
> >>>>> have
> >>>>>>>>>> concentrated on Classic in particular. I think it's worth
> >>>>> discussing
> >>>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
> >>>> the
> >>>>> details
> >>>>>>>>>> of why a migration makes (or doesn't make) sense and what the
> >>>>> challenges
> >>>>>>>>>> may be.
> >>>>>>>>>>
> >>>>>>>>>> To this end I've put together this document [1]. I hope it will
> >>>>> be of
> >>>>>>>>>> service to the community as we consider this option.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Justin
> >>>>>>>>>>
> >>>>>>>>>> [1]
> >>>>>>>>>>
> >>>>>
> >>>>
> >> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >>>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Clebert Suconic
> >>>>>
> >>>>
> >>
> >>
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Just a reminder: even if we use GitHub Discussions, we should always
send a pointer on the mailing list. As we say at Apache: "if it
doesn't occur on the mailing list, it never occurred".

Thanks
Regards
JB

On Mon, Apr 8, 2024 at 6:27 PM Matt Pavlovich <ma...@gmail.com> wrote:
>
> Got it, that makes sense. I think we could achieve the same effect w/ a private repo (ie "activmeq-pmc”) and enable what ever product features makes sense— issues, discussion, etc.
>
> I agree, moving off of mailing list would be beneficial for certain discussions (esp security reports) b/c of things like attachments, links, etc often become a security challenge w/ email.
>
> -Matt
>
> > On Apr 5, 2024, at 6:58 PM, Clebert Suconic <cl...@gmail.com> wrote:
> >
> > I haven’t used it on the Apache Jira but I use private comments all the
> > time on my company JIRA for things that would be related to security and
> > injeritently private.
> >
> > I thought we could eventually start using a feature like that and I thought
> > it would be a nice feature to keep.  But if everybody think we should keep
> > everything open and just use private list for private comments that’s fine.
> >
> > On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com> wrote:
> >
> >> Hi Clebert-
> >>
> >> How widely used are private comments today?
> >>
> >> I ran a search and I do not see any private comments in use with the
> >> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
> >> JQL incorrect?
> >>
> >> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> >> project = ARTEMIS AND issueFunction in commented(“role PMC")
> >>
> >> An available solution would be to use a private GH repo would secure all
> >> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> >> could have issues-only or discussion-only for CVE discussions.
> >>
> >> I think private comment is a wonky concept, as it is easy to get that
> >> toggled incorrectly. I think it is better to restrict access to a secured
> >> area vs trying to feather comments.
> >>
> >> Thanks,
> >> Matt
> >>
> >>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <cl...@gmail.com>
> >> wrote:
> >>>
> >>> Is there a private comment capability on GitHub?  To me that’s a breaking
> >>> deal feature and I have never seen it.
> >>>
> >>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> >>> bruscinodf@gmail.com> wrote:
> >>>
> >>>> I don't have a strong opinion on migrating from Jira to GitHub Issues.
> >>>> I would prefer GitHub Issues only for its better integration and because
> >>>> new users that reach from the GitHub repository could be confused to not
> >>>> find the `Issues` tabs (most of the GitHub projects use it).
> >>>>
> >>>> Also GitHub Issues has a good REST interface, I'm using it in
> >>>> GithubIssueManager[1].
> >>>>
> >>>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >>>>
> >>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suconic@gmail.com
> >>>
> >>>> wrote:
> >>>>
> >>>>> I would prefer to keep JIRA for their REST interface.
> >>>>>
> >>>>> Also: one thing to notice is the possibility of using private comments
> >>>>> in JIRA. Say you ever have a security issue. I think you can have PMC
> >>>>> private comments on JIRAs. I'm not sure you have the same in github
> >>>>> issues.
> >>>>>
> >>>>>
> >>>>> I didn't see a note about private comments on Justin's detailed doc
> >>>>> (nice Doc BTW), but the private comments may be handy on handling
> >>>>> sensitive issues.
> >>>>>
> >>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
> >> robbie.gemmell@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> The 'track version as Project' thing is interesting, though kinda
> >>>>>> further underscores the limitations of Milestones which are really the
> >>>>>> main surfaced way of handling versions.
> >>>>>>
> >>>>>> I'll bet some folks on the 'users' side of things looking at released
> >>>>>> issues later would even miss that you are doing that (I would), since
> >>>>>> Projects are kinda separate and get even further hidden away upon
> >>>>>> completion; closed Projects are hidden/collapsed in the Issue/PR view
> >>>>>> on expectations they are no longer 'interesting', requiring you to
> >>>>>> spot that and expand the closed-projects view on each Issue/PR to see
> >>>>>> the Project later. Which to be fair I think is actually decent
> >>>>>> behaviour in general for their main use cases, since they aren't
> >>>>>> really aimed to be used as versions but more for using the 'swimlane'
> >>>>>> etc views given for managing/planning overall outstanding tasks to a
> >>>>>> point of completion and will then most typically be
> >>>>>> forgotten/less-interesting detail.
> >>>>>>
> >>>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> >>>>>> <ch...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> I am also on the Accumulo PMC and on that project we use Github
> >>>> issues
> >>>>>>> and no longer use Jira. This switch was made before my time so I'm
> >>>> not
> >>>>>>> sure of the reasoning. Personally, I don't really care too much
> >>>> either
> >>>>>>> way as I've used both but I will just point out 2 things from my
> >>>>>>> experience with it.
> >>>>>>>
> >>>>>>> 1) For version tracking, we use projects and not milestones. I don't
> >>>>>>> know if this is the best way to do things but that's what we have
> >>>> been
> >>>>>>> using and seems to work ok as you can list multiple projects
> >>>>>>> (versions) for an Issue or PR:
> >>>>>>> https://github.com/apache/accumulo/projects?type=classic
> >>>>>>>
> >>>>>>> 2) Robbie's point about whether or not Issues get opened is a really
> >>>>>>> good point and something that is not consistent at all in Accumulo.
> >>>>>>> What I have found is it is all over the place. In some cases people
> >>>>>>> just open PRs and essentially are self documenting issues with the
> >>>>>>> fix. In other cases people open up issues and then open up PRs. It
> >>>>>>> does get confusing sometimes since they share the same numbering and
> >>>>>>> name space. It may make sense to try and establish some guidelines if
> >>>>>>> we go with Github Issues just so we are consistent about it.
> >>>>>>>
> >>>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> >>>>> robbie.gemmell@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> To the later point around Discussions, I do think enabling those
> >>>>> could
> >>>>>>>>> be good either way since, just like with Jira, people will often
> >>>>>>>>> create Issues to ask questions rather than e.g mail a mailing
> >>>> list.
> >>>>>>>>> They might use a Discussion instead though.
> >>>>>>>>
> >>>>>>>> +1 agree that having discussions enabled would be an upgrade for
> >>>>> users, big improvement over mailing lists.
> >>>>>>>>
> >>>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
> >>>>>
> >>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> There's been a few threads about this general subject, but most
> >>>>> have
> >>>>>>>>>> concentrated on Classic in particular. I think it's worth
> >>>>> discussing
> >>>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
> >>>> the
> >>>>> details
> >>>>>>>>>> of why a migration makes (or doesn't make) sense and what the
> >>>>> challenges
> >>>>>>>>>> may be.
> >>>>>>>>>>
> >>>>>>>>>> To this end I've put together this document [1]. I hope it will
> >>>>> be of
> >>>>>>>>>> service to the community as we consider this option.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Justin
> >>>>>>>>>>
> >>>>>>>>>> [1]
> >>>>>>>>>>
> >>>>>
> >>>>
> >> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >>>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Clebert Suconic
> >>>>>
> >>>>
> >>
> >>
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@gmail.com>]

Got it, that makes sense. I think we could achieve the same effect w/ a private repo (ie "activmeq-pmc”) and enable what ever product features makes sense— issues, discussion, etc.  

I agree, moving off of mailing list would be beneficial for certain discussions (esp security reports) b/c of things like attachments, links, etc often become a security challenge w/ email.

-Matt

> On Apr 5, 2024, at 6:58 PM, Clebert Suconic <cl...@gmail.com> wrote:
> 
> I haven’t used it on the Apache Jira but I use private comments all the
> time on my company JIRA for things that would be related to security and
> injeritently private.
> 
> I thought we could eventually start using a feature like that and I thought
> it would be a nice feature to keep.  But if everybody think we should keep
> everything open and just use private list for private comments that’s fine.
> 
> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com> wrote:
> 
>> Hi Clebert-
>> 
>> How widely used are private comments today?
>> 
>> I ran a search and I do not see any private comments in use with the
>> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
>> JQL incorrect?
>> 
>> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
>> project = ARTEMIS AND issueFunction in commented(“role PMC")
>> 
>> An available solution would be to use a private GH repo would secure all
>> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
>> could have issues-only or discussion-only for CVE discussions.
>> 
>> I think private comment is a wonky concept, as it is easy to get that
>> toggled incorrectly. I think it is better to restrict access to a secured
>> area vs trying to feather comments.
>> 
>> Thanks,
>> Matt
>> 
>>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <cl...@gmail.com>
>> wrote:
>>> 
>>> Is there a private comment capability on GitHub?  To me that’s a breaking
>>> deal feature and I have never seen it.
>>> 
>>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
>>> bruscinodf@gmail.com> wrote:
>>> 
>>>> I don't have a strong opinion on migrating from Jira to GitHub Issues.
>>>> I would prefer GitHub Issues only for its better integration and because
>>>> new users that reach from the GitHub repository could be confused to not
>>>> find the `Issues` tabs (most of the GitHub projects use it).
>>>> 
>>>> Also GitHub Issues has a good REST interface, I'm using it in
>>>> GithubIssueManager[1].
>>>> 
>>>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
>>>> 
>>>> [1]
>>>> 
>>>> 
>> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
>>>> 
>>>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suconic@gmail.com
>>> 
>>>> wrote:
>>>> 
>>>>> I would prefer to keep JIRA for their REST interface.
>>>>> 
>>>>> Also: one thing to notice is the possibility of using private comments
>>>>> in JIRA. Say you ever have a security issue. I think you can have PMC
>>>>> private comments on JIRAs. I'm not sure you have the same in github
>>>>> issues.
>>>>> 
>>>>> 
>>>>> I didn't see a note about private comments on Justin's detailed doc
>>>>> (nice Doc BTW), but the private comments may be handy on handling
>>>>> sensitive issues.
>>>>> 
>>>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
>> robbie.gemmell@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>> The 'track version as Project' thing is interesting, though kinda
>>>>>> further underscores the limitations of Milestones which are really the
>>>>>> main surfaced way of handling versions.
>>>>>> 
>>>>>> I'll bet some folks on the 'users' side of things looking at released
>>>>>> issues later would even miss that you are doing that (I would), since
>>>>>> Projects are kinda separate and get even further hidden away upon
>>>>>> completion; closed Projects are hidden/collapsed in the Issue/PR view
>>>>>> on expectations they are no longer 'interesting', requiring you to
>>>>>> spot that and expand the closed-projects view on each Issue/PR to see
>>>>>> the Project later. Which to be fair I think is actually decent
>>>>>> behaviour in general for their main use cases, since they aren't
>>>>>> really aimed to be used as versions but more for using the 'swimlane'
>>>>>> etc views given for managing/planning overall outstanding tasks to a
>>>>>> point of completion and will then most typically be
>>>>>> forgotten/less-interesting detail.
>>>>>> 
>>>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
>>>>>> <ch...@gmail.com> wrote:
>>>>>>> 
>>>>>>> I am also on the Accumulo PMC and on that project we use Github
>>>> issues
>>>>>>> and no longer use Jira. This switch was made before my time so I'm
>>>> not
>>>>>>> sure of the reasoning. Personally, I don't really care too much
>>>> either
>>>>>>> way as I've used both but I will just point out 2 things from my
>>>>>>> experience with it.
>>>>>>> 
>>>>>>> 1) For version tracking, we use projects and not milestones. I don't
>>>>>>> know if this is the best way to do things but that's what we have
>>>> been
>>>>>>> using and seems to work ok as you can list multiple projects
>>>>>>> (versions) for an Issue or PR:
>>>>>>> https://github.com/apache/accumulo/projects?type=classic
>>>>>>> 
>>>>>>> 2) Robbie's point about whether or not Issues get opened is a really
>>>>>>> good point and something that is not consistent at all in Accumulo.
>>>>>>> What I have found is it is all over the place. In some cases people
>>>>>>> just open PRs and essentially are self documenting issues with the
>>>>>>> fix. In other cases people open up issues and then open up PRs. It
>>>>>>> does get confusing sometimes since they share the same numbering and
>>>>>>> name space. It may make sense to try and establish some guidelines if
>>>>>>> we go with Github Issues just so we are consistent about it.
>>>>>>> 
>>>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
>>>>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
>>>>> robbie.gemmell@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> To the later point around Discussions, I do think enabling those
>>>>> could
>>>>>>>>> be good either way since, just like with Jira, people will often
>>>>>>>>> create Issues to ask questions rather than e.g mail a mailing
>>>> list.
>>>>>>>>> They might use a Discussion instead though.
>>>>>>>> 
>>>>>>>> +1 agree that having discussions enabled would be an upgrade for
>>>>> users, big improvement over mailing lists.
>>>>>>>> 
>>>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
>>>>> 
>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> There's been a few threads about this general subject, but most
>>>>> have
>>>>>>>>>> concentrated on Classic in particular. I think it's worth
>>>>> discussing
>>>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
>>>> the
>>>>> details
>>>>>>>>>> of why a migration makes (or doesn't make) sense and what the
>>>>> challenges
>>>>>>>>>> may be.
>>>>>>>>>> 
>>>>>>>>>> To this end I've put together this document [1]. I hope it will
>>>>> be of
>>>>>>>>>> service to the community as we consider this option.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Justin
>>>>>>>>>> 
>>>>>>>>>> [1]
>>>>>>>>>> 
>>>>> 
>>>> 
>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Clebert Suconic
>>>>> 
>>>> 
>> 
>> 

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Clebert Suconic <cl...@gmail.com>]

I haven’t used it on the Apache Jira but I use private comments all the
time on my company JIRA for things that would be related to security and
injeritently private.

I thought we could eventually start using a feature like that and I thought
it would be a nice feature to keep.  But if everybody think we should keep
everything open and just use private list for private comments that’s fine.

On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich <ma...@gmail.com> wrote:

> Hi Clebert-
>
> How widely used are private comments today?
>
> I ran a search and I do not see any private comments in use with the
> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
> JQL incorrect?
>
> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> project = ARTEMIS AND issueFunction in commented(“role PMC")
>
> An available solution would be to use a private GH repo would secure all
> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> could have issues-only or discussion-only for CVE discussions.
>
> I think private comment is a wonky concept, as it is easy to get that
> toggled incorrectly. I think it is better to restrict access to a secured
> area vs trying to feather comments.
>
> Thanks,
> Matt
>
> > On Apr 5, 2024, at 11:47 AM, Clebert Suconic <cl...@gmail.com>
> wrote:
> >
> > Is there a private comment capability on GitHub?  To me that’s a breaking
> > deal feature and I have never seen it.
> >
> > On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> > bruscinodf@gmail.com> wrote:
> >
> >> I don't have a strong opinion on migrating from Jira to GitHub Issues.
> >> I would prefer GitHub Issues only for its better integration and because
> >> new users that reach from the GitHub repository could be confused to not
> >> find the `Issues` tabs (most of the GitHub projects use it).
> >>
> >> Also GitHub Issues has a good REST interface, I'm using it in
> >> GithubIssueManager[1].
> >>
> >> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
> >>
> >> [1]
> >>
> >>
> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
> >>
> >> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suconic@gmail.com
> >
> >> wrote:
> >>
> >>> I would prefer to keep JIRA for their REST interface.
> >>>
> >>> Also: one thing to notice is the possibility of using private comments
> >>> in JIRA. Say you ever have a security issue. I think you can have PMC
> >>> private comments on JIRAs. I'm not sure you have the same in github
> >>> issues.
> >>>
> >>>
> >>> I didn't see a note about private comments on Justin's detailed doc
> >>> (nice Doc BTW), but the private comments may be handy on handling
> >>> sensitive issues.
> >>>
> >>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <
> robbie.gemmell@gmail.com>
> >>> wrote:
> >>>>
> >>>> The 'track version as Project' thing is interesting, though kinda
> >>>> further underscores the limitations of Milestones which are really the
> >>>> main surfaced way of handling versions.
> >>>>
> >>>> I'll bet some folks on the 'users' side of things looking at released
> >>>> issues later would even miss that you are doing that (I would), since
> >>>> Projects are kinda separate and get even further hidden away upon
> >>>> completion; closed Projects are hidden/collapsed in the Issue/PR view
> >>>> on expectations they are no longer 'interesting', requiring you to
> >>>> spot that and expand the closed-projects view on each Issue/PR to see
> >>>> the Project later. Which to be fair I think is actually decent
> >>>> behaviour in general for their main use cases, since they aren't
> >>>> really aimed to be used as versions but more for using the 'swimlane'
> >>>> etc views given for managing/planning overall outstanding tasks to a
> >>>> point of completion and will then most typically be
> >>>> forgotten/less-interesting detail.
> >>>>
> >>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> >>>> <ch...@gmail.com> wrote:
> >>>>>
> >>>>> I am also on the Accumulo PMC and on that project we use Github
> >> issues
> >>>>> and no longer use Jira. This switch was made before my time so I'm
> >> not
> >>>>> sure of the reasoning. Personally, I don't really care too much
> >> either
> >>>>> way as I've used both but I will just point out 2 things from my
> >>>>> experience with it.
> >>>>>
> >>>>> 1) For version tracking, we use projects and not milestones. I don't
> >>>>> know if this is the best way to do things but that's what we have
> >> been
> >>>>> using and seems to work ok as you can list multiple projects
> >>>>> (versions) for an Issue or PR:
> >>>>> https://github.com/apache/accumulo/projects?type=classic
> >>>>>
> >>>>> 2) Robbie's point about whether or not Issues get opened is a really
> >>>>> good point and something that is not consistent at all in Accumulo.
> >>>>> What I have found is it is all over the place. In some cases people
> >>>>> just open PRs and essentially are self documenting issues with the
> >>>>> fix. In other cases people open up issues and then open up PRs. It
> >>>>> does get confusing sometimes since they share the same numbering and
> >>>>> name space. It may make sense to try and establish some guidelines if
> >>>>> we go with Github Issues just so we are consistent about it.
> >>>>>
> >>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> >>> robbie.gemmell@gmail.com> wrote:
> >>>>>>>
> >>>>>>> To the later point around Discussions, I do think enabling those
> >>> could
> >>>>>>> be good either way since, just like with Jira, people will often
> >>>>>>> create Issues to ask questions rather than e.g mail a mailing
> >> list.
> >>>>>>> They might use a Discussion instead though.
> >>>>>>
> >>>>>> +1 agree that having discussions enabled would be an upgrade for
> >>> users, big improvement over mailing lists.
> >>>>>>
> >>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
> >>>
> >>> wrote:
> >>>>>>>>
> >>>>>>>> There's been a few threads about this general subject, but most
> >>> have
> >>>>>>>> concentrated on Classic in particular. I think it's worth
> >>> discussing
> >>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
> >> the
> >>> details
> >>>>>>>> of why a migration makes (or doesn't make) sense and what the
> >>> challenges
> >>>>>>>> may be.
> >>>>>>>>
> >>>>>>>> To this end I've put together this document [1]. I hope it will
> >>> be of
> >>>>>>>> service to the community as we consider this option.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Justin
> >>>>>>>>
> >>>>>>>> [1]
> >>>>>>>>
> >>>
> >>
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >>>>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Clebert Suconic
> >>>
> >>
>
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@gmail.com>]

Hi Clebert-

How widely used are private comments today?

I ran a search and I do not see any private comments in use with the ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the JQL incorrect?

project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
project = ARTEMIS AND issueFunction in commented(“role PMC")

An available solution would be to use a private GH repo would secure all the items — code, issues, etc.. from unprivileged users. A PMC-only repo could have issues-only or discussion-only for CVE discussions.

I think private comment is a wonky concept, as it is easy to get that toggled incorrectly. I think it is better to restrict access to a secured area vs trying to feather comments.

Thanks,
Matt

> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <cl...@gmail.com> wrote:
> 
> Is there a private comment capability on GitHub?  To me that’s a breaking
> deal feature and I have never seen it.
> 
> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> bruscinodf@gmail.com> wrote:
> 
>> I don't have a strong opinion on migrating from Jira to GitHub Issues.
>> I would prefer GitHub Issues only for its better integration and because
>> new users that reach from the GitHub repository could be confused to not
>> find the `Issues` tabs (most of the GitHub projects use it).
>> 
>> Also GitHub Issues has a good REST interface, I'm using it in
>> GithubIssueManager[1].
>> 
>> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
>> 
>> [1]
>> 
>> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
>> 
>> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <cl...@gmail.com>
>> wrote:
>> 
>>> I would prefer to keep JIRA for their REST interface.
>>> 
>>> Also: one thing to notice is the possibility of using private comments
>>> in JIRA. Say you ever have a security issue. I think you can have PMC
>>> private comments on JIRAs. I'm not sure you have the same in github
>>> issues.
>>> 
>>> 
>>> I didn't see a note about private comments on Justin's detailed doc
>>> (nice Doc BTW), but the private comments may be handy on handling
>>> sensitive issues.
>>> 
>>> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <ro...@gmail.com>
>>> wrote:
>>>> 
>>>> The 'track version as Project' thing is interesting, though kinda
>>>> further underscores the limitations of Milestones which are really the
>>>> main surfaced way of handling versions.
>>>> 
>>>> I'll bet some folks on the 'users' side of things looking at released
>>>> issues later would even miss that you are doing that (I would), since
>>>> Projects are kinda separate and get even further hidden away upon
>>>> completion; closed Projects are hidden/collapsed in the Issue/PR view
>>>> on expectations they are no longer 'interesting', requiring you to
>>>> spot that and expand the closed-projects view on each Issue/PR to see
>>>> the Project later. Which to be fair I think is actually decent
>>>> behaviour in general for their main use cases, since they aren't
>>>> really aimed to be used as versions but more for using the 'swimlane'
>>>> etc views given for managing/planning overall outstanding tasks to a
>>>> point of completion and will then most typically be
>>>> forgotten/less-interesting detail.
>>>> 
>>>> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
>>>> <ch...@gmail.com> wrote:
>>>>> 
>>>>> I am also on the Accumulo PMC and on that project we use Github
>> issues
>>>>> and no longer use Jira. This switch was made before my time so I'm
>> not
>>>>> sure of the reasoning. Personally, I don't really care too much
>> either
>>>>> way as I've used both but I will just point out 2 things from my
>>>>> experience with it.
>>>>> 
>>>>> 1) For version tracking, we use projects and not milestones. I don't
>>>>> know if this is the best way to do things but that's what we have
>> been
>>>>> using and seems to work ok as you can list multiple projects
>>>>> (versions) for an Issue or PR:
>>>>> https://github.com/apache/accumulo/projects?type=classic
>>>>> 
>>>>> 2) Robbie's point about whether or not Issues get opened is a really
>>>>> good point and something that is not consistent at all in Accumulo.
>>>>> What I have found is it is all over the place. In some cases people
>>>>> just open PRs and essentially are self documenting issues with the
>>>>> fix. In other cases people open up issues and then open up PRs. It
>>>>> does get confusing sometimes since they share the same numbering and
>>>>> name space. It may make sense to try and establish some guidelines if
>>>>> we go with Github Issues just so we are consistent about it.
>>>>> 
>>>>> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
>>> robbie.gemmell@gmail.com> wrote:
>>>>>>> 
>>>>>>> To the later point around Discussions, I do think enabling those
>>> could
>>>>>>> be good either way since, just like with Jira, people will often
>>>>>>> create Issues to ask questions rather than e.g mail a mailing
>> list.
>>>>>>> They might use a Discussion instead though.
>>>>>> 
>>>>>> +1 agree that having discussions enabled would be an upgrade for
>>> users, big improvement over mailing lists.
>>>>>> 
>>>>>>> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
>>> 
>>> wrote:
>>>>>>>> 
>>>>>>>> There's been a few threads about this general subject, but most
>>> have
>>>>>>>> concentrated on Classic in particular. I think it's worth
>>> discussing
>>>>>>>> migration of ActiveMQ as a whole and diving a bit deeper into
>> the
>>> details
>>>>>>>> of why a migration makes (or doesn't make) sense and what the
>>> challenges
>>>>>>>> may be.
>>>>>>>> 
>>>>>>>> To this end I've put together this document [1]. I hope it will
>>> be of
>>>>>>>> service to the community as we consider this option.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Justin
>>>>>>>> 
>>>>>>>> [1]
>>>>>>>> 
>>> 
>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>>>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Clebert Suconic
>>> 
>> 

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Clebert Suconic <cl...@gmail.com>]

Is there a private comment capability on GitHub?  To me that’s a breaking
deal feature and I have never seen it.

On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
bruscinodf@gmail.com> wrote:

> I don't have a strong opinion on migrating from Jira to GitHub Issues.
> I would prefer GitHub Issues only for its better integration and because
> new users that reach from the GitHub repository could be confused to not
> find the `Issues` tabs (most of the GitHub projects use it).
>
> Also GitHub Issues has a good REST interface, I'm using it in
> GithubIssueManager[1].
>
> @Justin Bertram <jb...@apache.org> thanks the detailed doc!!!
>
> [1]
>
> https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java
>
> On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <cl...@gmail.com>
> wrote:
>
> > I would prefer to keep JIRA for their REST interface.
> >
> > Also: one thing to notice is the possibility of using private comments
> > in JIRA. Say you ever have a security issue. I think you can have PMC
> > private comments on JIRAs. I'm not sure you have the same in github
> > issues.
> >
> >
> > I didn't see a note about private comments on Justin's detailed doc
> > (nice Doc BTW), but the private comments may be handy on handling
> > sensitive issues.
> >
> > On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <ro...@gmail.com>
> > wrote:
> > >
> > > The 'track version as Project' thing is interesting, though kinda
> > > further underscores the limitations of Milestones which are really the
> > > main surfaced way of handling versions.
> > >
> > > I'll bet some folks on the 'users' side of things looking at released
> > > issues later would even miss that you are doing that (I would), since
> > > Projects are kinda separate and get even further hidden away upon
> > > completion; closed Projects are hidden/collapsed in the Issue/PR view
> > > on expectations they are no longer 'interesting', requiring you to
> > > spot that and expand the closed-projects view on each Issue/PR to see
> > > the Project later. Which to be fair I think is actually decent
> > > behaviour in general for their main use cases, since they aren't
> > > really aimed to be used as versions but more for using the 'swimlane'
> > > etc views given for managing/planning overall outstanding tasks to a
> > > point of completion and will then most typically be
> > > forgotten/less-interesting detail.
> > >
> > > On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> > > <ch...@gmail.com> wrote:
> > > >
> > > > I am also on the Accumulo PMC and on that project we use Github
> issues
> > > > and no longer use Jira. This switch was made before my time so I'm
> not
> > > > sure of the reasoning. Personally, I don't really care too much
> either
> > > > way as I've used both but I will just point out 2 things from my
> > > > experience with it.
> > > >
> > > > 1) For version tracking, we use projects and not milestones. I don't
> > > > know if this is the best way to do things but that's what we have
> been
> > > > using and seems to work ok as you can list multiple projects
> > > > (versions) for an Issue or PR:
> > > > https://github.com/apache/accumulo/projects?type=classic
> > > >
> > > > 2) Robbie's point about whether or not Issues get opened is a really
> > > > good point and something that is not consistent at all in Accumulo.
> > > > What I have found is it is all over the place. In some cases people
> > > > just open PRs and essentially are self documenting issues with the
> > > > fix. In other cases people open up issues and then open up PRs. It
> > > > does get confusing sometimes since they share the same numbering and
> > > > name space. It may make sense to try and establish some guidelines if
> > > > we go with Github Issues just so we are consistent about it.
> > > >
> > > > On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
> > wrote:
> > > > >
> > > > >
> > > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> > robbie.gemmell@gmail.com> wrote:
> > > > > >
> > > > > > To the later point around Discussions, I do think enabling those
> > could
> > > > > > be good either way since, just like with Jira, people will often
> > > > > > create Issues to ask questions rather than e.g mail a mailing
> list.
> > > > > > They might use a Discussion instead though.
> > > > >
> > > > > +1 agree that having discussions enabled would be an upgrade for
> > users, big improvement over mailing lists.
> > > > >
> > > > > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbertram@apache.org
> >
> > wrote:
> > > > > >>
> > > > > >> There's been a few threads about this general subject, but most
> > have
> > > > > >> concentrated on Classic in particular. I think it's worth
> > discussing
> > > > > >> migration of ActiveMQ as a whole and diving a bit deeper into
> the
> > details
> > > > > >> of why a migration makes (or doesn't make) sense and what the
> > challenges
> > > > > >> may be.
> > > > > >>
> > > > > >> To this end I've put together this document [1]. I hope it will
> > be of
> > > > > >> service to the community as we consider this option.
> > > > > >>
> > > > > >>
> > > > > >> Justin
> > > > > >>
> > > > > >> [1]
> > > > > >>
> >
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > > > >
> >
> >
> >
> > --
> > Clebert Suconic
> >
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Domenico Francesco Bruscino <br...@gmail.com>]

I don't have a strong opinion on migrating from Jira to GitHub Issues.
I would prefer GitHub Issues only for its better integration and because
new users that reach from the GitHub repository could be confused to not
find the `Issues` tabs (most of the GitHub projects use it).

Also GitHub Issues has a good REST interface, I'm using it in
GithubIssueManager[1].

@Justin Bertram <jb...@apache.org> thanks the detailed doc!!!

[1]
https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java

On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <cl...@gmail.com>
wrote:

> I would prefer to keep JIRA for their REST interface.
>
> Also: one thing to notice is the possibility of using private comments
> in JIRA. Say you ever have a security issue. I think you can have PMC
> private comments on JIRAs. I'm not sure you have the same in github
> issues.
>
>
> I didn't see a note about private comments on Justin's detailed doc
> (nice Doc BTW), but the private comments may be handy on handling
> sensitive issues.
>
> On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <ro...@gmail.com>
> wrote:
> >
> > The 'track version as Project' thing is interesting, though kinda
> > further underscores the limitations of Milestones which are really the
> > main surfaced way of handling versions.
> >
> > I'll bet some folks on the 'users' side of things looking at released
> > issues later would even miss that you are doing that (I would), since
> > Projects are kinda separate and get even further hidden away upon
> > completion; closed Projects are hidden/collapsed in the Issue/PR view
> > on expectations they are no longer 'interesting', requiring you to
> > spot that and expand the closed-projects view on each Issue/PR to see
> > the Project later. Which to be fair I think is actually decent
> > behaviour in general for their main use cases, since they aren't
> > really aimed to be used as versions but more for using the 'swimlane'
> > etc views given for managing/planning overall outstanding tasks to a
> > point of completion and will then most typically be
> > forgotten/less-interesting detail.
> >
> > On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> > <ch...@gmail.com> wrote:
> > >
> > > I am also on the Accumulo PMC and on that project we use Github issues
> > > and no longer use Jira. This switch was made before my time so I'm not
> > > sure of the reasoning. Personally, I don't really care too much either
> > > way as I've used both but I will just point out 2 things from my
> > > experience with it.
> > >
> > > 1) For version tracking, we use projects and not milestones. I don't
> > > know if this is the best way to do things but that's what we have been
> > > using and seems to work ok as you can list multiple projects
> > > (versions) for an Issue or PR:
> > > https://github.com/apache/accumulo/projects?type=classic
> > >
> > > 2) Robbie's point about whether or not Issues get opened is a really
> > > good point and something that is not consistent at all in Accumulo.
> > > What I have found is it is all over the place. In some cases people
> > > just open PRs and essentially are self documenting issues with the
> > > fix. In other cases people open up issues and then open up PRs. It
> > > does get confusing sometimes since they share the same numbering and
> > > name space. It may make sense to try and establish some guidelines if
> > > we go with Github Issues just so we are consistent about it.
> > >
> > > On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com>
> wrote:
> > > >
> > > >
> > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <
> robbie.gemmell@gmail.com> wrote:
> > > > >
> > > > > To the later point around Discussions, I do think enabling those
> could
> > > > > be good either way since, just like with Jira, people will often
> > > > > create Issues to ask questions rather than e.g mail a mailing list.
> > > > > They might use a Discussion instead though.
> > > >
> > > > +1 agree that having discussions enabled would be an upgrade for
> users, big improvement over mailing lists.
> > > >
> > > > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jb...@apache.org>
> wrote:
> > > > >>
> > > > >> There's been a few threads about this general subject, but most
> have
> > > > >> concentrated on Classic in particular. I think it's worth
> discussing
> > > > >> migration of ActiveMQ as a whole and diving a bit deeper into the
> details
> > > > >> of why a migration makes (or doesn't make) sense and what the
> challenges
> > > > >> may be.
> > > > >>
> > > > >> To this end I've put together this document [1]. I hope it will
> be of
> > > > >> service to the community as we consider this option.
> > > > >>
> > > > >>
> > > > >> Justin
> > > > >>
> > > > >> [1]
> > > > >>
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > > >
>
>
>
> --
> Clebert Suconic
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Clebert Suconic <cl...@gmail.com>]

I would prefer to keep JIRA for their REST interface.

Also: one thing to notice is the possibility of using private comments
in JIRA. Say you ever have a security issue. I think you can have PMC
private comments on JIRAs. I'm not sure you have the same in github
issues.


I didn't see a note about private comments on Justin's detailed doc
(nice Doc BTW), but the private comments may be handy on handling
sensitive issues.

On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <ro...@gmail.com> wrote:
>
> The 'track version as Project' thing is interesting, though kinda
> further underscores the limitations of Milestones which are really the
> main surfaced way of handling versions.
>
> I'll bet some folks on the 'users' side of things looking at released
> issues later would even miss that you are doing that (I would), since
> Projects are kinda separate and get even further hidden away upon
> completion; closed Projects are hidden/collapsed in the Issue/PR view
> on expectations they are no longer 'interesting', requiring you to
> spot that and expand the closed-projects view on each Issue/PR to see
> the Project later. Which to be fair I think is actually decent
> behaviour in general for their main use cases, since they aren't
> really aimed to be used as versions but more for using the 'swimlane'
> etc views given for managing/planning overall outstanding tasks to a
> point of completion and will then most typically be
> forgotten/less-interesting detail.
>
> On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
> <ch...@gmail.com> wrote:
> >
> > I am also on the Accumulo PMC and on that project we use Github issues
> > and no longer use Jira. This switch was made before my time so I'm not
> > sure of the reasoning. Personally, I don't really care too much either
> > way as I've used both but I will just point out 2 things from my
> > experience with it.
> >
> > 1) For version tracking, we use projects and not milestones. I don't
> > know if this is the best way to do things but that's what we have been
> > using and seems to work ok as you can list multiple projects
> > (versions) for an Issue or PR:
> > https://github.com/apache/accumulo/projects?type=classic
> >
> > 2) Robbie's point about whether or not Issues get opened is a really
> > good point and something that is not consistent at all in Accumulo.
> > What I have found is it is all over the place. In some cases people
> > just open PRs and essentially are self documenting issues with the
> > fix. In other cases people open up issues and then open up PRs. It
> > does get confusing sometimes since they share the same numbering and
> > name space. It may make sense to try and establish some guidelines if
> > we go with Github Issues just so we are consistent about it.
> >
> > On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com> wrote:
> > >
> > >
> > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <ro...@gmail.com> wrote:
> > > >
> > > > To the later point around Discussions, I do think enabling those could
> > > > be good either way since, just like with Jira, people will often
> > > > create Issues to ask questions rather than e.g mail a mailing list.
> > > > They might use a Discussion instead though.
> > >
> > > +1 agree that having discussions enabled would be an upgrade for users, big improvement over mailing lists.
> > >
> > > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jb...@apache.org> wrote:
> > > >>
> > > >> There's been a few threads about this general subject, but most have
> > > >> concentrated on Classic in particular. I think it's worth discussing
> > > >> migration of ActiveMQ as a whole and diving a bit deeper into the details
> > > >> of why a migration makes (or doesn't make) sense and what the challenges
> > > >> may be.
> > > >>
> > > >> To this end I've put together this document [1]. I hope it will be of
> > > >> service to the community as we consider this option.
> > > >>
> > > >>
> > > >> Justin
> > > >>
> > > >> [1]
> > > >> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> > >



-- 
Clebert Suconic

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell <ro...@gmail.com>]

The 'track version as Project' thing is interesting, though kinda
further underscores the limitations of Milestones which are really the
main surfaced way of handling versions.

I'll bet some folks on the 'users' side of things looking at released
issues later would even miss that you are doing that (I would), since
Projects are kinda separate and get even further hidden away upon
completion; closed Projects are hidden/collapsed in the Issue/PR view
on expectations they are no longer 'interesting', requiring you to
spot that and expand the closed-projects view on each Issue/PR to see
the Project later. Which to be fair I think is actually decent
behaviour in general for their main use cases, since they aren't
really aimed to be used as versions but more for using the 'swimlane'
etc views given for managing/planning overall outstanding tasks to a
point of completion and will then most typically be
forgotten/less-interesting detail.

On Thu, 4 Apr 2024 at 22:52, Christopher Shannon
<ch...@gmail.com> wrote:
>
> I am also on the Accumulo PMC and on that project we use Github issues
> and no longer use Jira. This switch was made before my time so I'm not
> sure of the reasoning. Personally, I don't really care too much either
> way as I've used both but I will just point out 2 things from my
> experience with it.
>
> 1) For version tracking, we use projects and not milestones. I don't
> know if this is the best way to do things but that's what we have been
> using and seems to work ok as you can list multiple projects
> (versions) for an Issue or PR:
> https://github.com/apache/accumulo/projects?type=classic
>
> 2) Robbie's point about whether or not Issues get opened is a really
> good point and something that is not consistent at all in Accumulo.
> What I have found is it is all over the place. In some cases people
> just open PRs and essentially are self documenting issues with the
> fix. In other cases people open up issues and then open up PRs. It
> does get confusing sometimes since they share the same numbering and
> name space. It may make sense to try and establish some guidelines if
> we go with Github Issues just so we are consistent about it.
>
> On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com> wrote:
> >
> >
> > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <ro...@gmail.com> wrote:
> > >
> > > To the later point around Discussions, I do think enabling those could
> > > be good either way since, just like with Jira, people will often
> > > create Issues to ask questions rather than e.g mail a mailing list.
> > > They might use a Discussion instead though.
> >
> > +1 agree that having discussions enabled would be an upgrade for users, big improvement over mailing lists.
> >
> > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jb...@apache.org> wrote:
> > >>
> > >> There's been a few threads about this general subject, but most have
> > >> concentrated on Classic in particular. I think it's worth discussing
> > >> migration of ActiveMQ as a whole and diving a bit deeper into the details
> > >> of why a migration makes (or doesn't make) sense and what the challenges
> > >> may be.
> > >>
> > >> To this end I've put together this document [1]. I hope it will be of
> > >> service to the community as we consider this option.
> > >>
> > >>
> > >> Justin
> > >>
> > >> [1]
> > >> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
> >

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Christopher Shannon <ch...@gmail.com>]

I am also on the Accumulo PMC and on that project we use Github issues
and no longer use Jira. This switch was made before my time so I'm not
sure of the reasoning. Personally, I don't really care too much either
way as I've used both but I will just point out 2 things from my
experience with it.

1) For version tracking, we use projects and not milestones. I don't
know if this is the best way to do things but that's what we have been
using and seems to work ok as you can list multiple projects
(versions) for an Issue or PR:
https://github.com/apache/accumulo/projects?type=classic

2) Robbie's point about whether or not Issues get opened is a really
good point and something that is not consistent at all in Accumulo.
What I have found is it is all over the place. In some cases people
just open PRs and essentially are self documenting issues with the
fix. In other cases people open up issues and then open up PRs. It
does get confusing sometimes since they share the same numbering and
name space. It may make sense to try and establish some guidelines if
we go with Github Issues just so we are consistent about it.

On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <ma...@gmail.com> wrote:
>
>
> > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <ro...@gmail.com> wrote:
> >
> > To the later point around Discussions, I do think enabling those could
> > be good either way since, just like with Jira, people will often
> > create Issues to ask questions rather than e.g mail a mailing list.
> > They might use a Discussion instead though.
>
> +1 agree that having discussions enabled would be an upgrade for users, big improvement over mailing lists.
>
> > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jb...@apache.org> wrote:
> >>
> >> There's been a few threads about this general subject, but most have
> >> concentrated on Classic in particular. I think it's worth discussing
> >> migration of ActiveMQ as a whole and diving a bit deeper into the details
> >> of why a migration makes (or doesn't make) sense and what the challenges
> >> may be.
> >>
> >> To this end I've put together this document [1]. I hope it will be of
> >> service to the community as we consider this option.
> >>
> >>
> >> Justin
> >>
> >> [1]
> >> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review
>

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Matt Pavlovich <ma...@gmail.com>]

> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell <ro...@gmail.com> wrote:
> 
> To the later point around Discussions, I do think enabling those could
> be good either way since, just like with Jira, people will often
> create Issues to ask questions rather than e.g mail a mailing list.
> They might use a Discussion instead though.

+1 agree that having discussions enabled would be an upgrade for users, big improvement over mailing lists.

> On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jb...@apache.org> wrote:
>> 
>> There's been a few threads about this general subject, but most have
>> concentrated on Classic in particular. I think it's worth discussing
>> migration of ActiveMQ as a whole and diving a bit deeper into the details
>> of why a migration makes (or doesn't make) sense and what the challenges
>> may be.
>> 
>> To this end I've put together this document [1]. I hope it will be of
>> service to the community as we consider this option.
>> 
>> 
>> Justin
>> 
>> [1]
>> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Robbie Gemmell <ro...@gmail.com>]

I prefer Jira for issue tracking, I think it's better at it,
particularly for cases like 5.x / 6.x having multiple active release
streams with lots of backports, given the limitations of Milestone
handling and how people tend to treat xref'ing to fully compensate for
that (i.e they often dont bother).

I would be fine with adopting Issues too though, I use Issues plenty
elsewhere where it's enabled by default and the only option anyway
hehe.

I expect most users reporting things would prefer Issues at this
point, especially anyone intende to raise a PR, and most particularly
all the folks without Jira accounts already (of course, I also think
many of those asking for accounts dont actually need one; see
Discussions note at end).

I dont actually think every component needs to use the exact same
labels etc. People are already used to just about every other GitHub
repo they encounter at this point which uses Issue having their own
labels. For me, the labels just need to make sense in themselves.
Though the default ones are simple, so I'd be fine with them, which
would then just happen to be consistent.

It's not clear to me anyone proposing to move to Issues actually
intended thus far to migrate any of the [open] issues from Jira to
Github Issues, so much as just start using Github Issues and thus
effectively 'clearing the cruft' by leaving it where it is, then
raising new issues going forward?

To the later point around Discussions, I do think enabling those could
be good either way since, just like with Jira, people will often
create Issues to ask questions rather than e.g mail a mailing list.
They might use a Discussion instead though.

On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jb...@apache.org> wrote:
>
> There's been a few threads about this general subject, but most have
> concentrated on Classic in particular. I think it's worth discussing
> migration of ActiveMQ as a whole and diving a bit deeper into the details
> of why a migration makes (or doesn't make) sense and what the challenges
> may be.
>
> To this end I've put together this document [1]. I hope it will be of
> service to the community as we consider this option.
>
>
> Justin
>
> [1]
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review

Re: [DISCUSS] Migrate from Jira to GitHub Issues

[Étienne Hossack <ac...@hossack.me>]

This is a good summary Justin. As someone who mostly follows issues these days-as opposed to contributing-a few things to add, having used both to manage work:

* Github has "projects" which allow you to organize tasks across repos -- which in some ways is helpful, but you have to know to look for the projects
* Github milestones are a bit weird, and not as intuitive as target/fix versions, but they suffice -- as Justin points out, deciding how to use those, and reference issues/releases is important
* The two tools are mostly comparable with some drawbacks to either: github is about 3 quarters as mature as Jira in many ways IMO, but if it saves the PMC time, that's a big draw.
* I agree that the intent of making everything more approachable by using Github is a worthwhile goal, and probably a likely result -- especially if releases are being tagged + documented in the project
* Seeing a repo with a ton of issues on github isn't really the best visual experience, as the github UI isn't super clear, so probably setting up/linking some project views would be the way to go


On Tue, 2 Apr 2024, at 12:52 PM, Justin Bertram wrote:
> There's been a few threads about this general subject, but most have
> concentrated on Classic in particular. I think it's worth discussing
> migration of ActiveMQ as a whole and diving a bit deeper into the details
> of why a migration makes (or doesn't make) sense and what the challenges
> may be.
>
> To this end I've put together this document [1]. I hope it will be of
> service to the community as we consider this option.
>
>
> Justin
>
> [1]
> https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review