> As we have two components on Jira (one for ActiveMQ, one for Artemis)...
We have 2 brokers and 2 clients under the ActiveMQ umbrella each of which have their own Jira project [1]. > ...I proposed "only" for ActiveMQ. I realize you're only proposing this for ActiveMQ "Classic" 6.0 and beyond. My point, at least in part, is that I think we should consider this across the entire project rather than just for ActiveMQ "Classic" because a lack of consistency will be detrimental for users. Also, if the reasons for migrating are compelling for ActiveMQ "Classic" then I expect they would also be compelling for the rest of the ActiveMQ components. > The general idea is to use a more modern approach... Can you elaborate on "more modern"? This seems a bit subjective to me. > not need to request a specific Jira account, just use github I'm in favor of reducing "barriers to entry" which I believe is your goal here. Is this the main problem with Jira at the moment? At the moment users must request a Jira account as a way to mitigate spam. However, folks can also report issues via the mailing list or Slack and someone (e.g. a committer) can create a Jira on their behalf as part of fixing the issue. I've done this a number of times. Of course, even in this case users have to join the mailing list and potentially Slack which are still barriers to entry. However, having a GitHub account is also a barrier to entry and non-developer users (e.g. admins) likely won't have one. Therefore, by migrating to GitHub Issues we would be removing a barrier only for those users who already have a GitHub account. Without clear data we don't know what kind of real impact that will have. Out of the all the barriers to entry I think joining the mailing list is actually the lowest since all it requires is an email address (i.e. no "account"). Of course, we will have to deal with spam either way. > increase our contributors as the "new" comers are more familiar with GH ecosystem (outside of Apache) Jira is a widely deployed and well-known issue management platform so I think it's hard to say conclusively that it is less familiar than GitHub Issues. Is there data to suggest that moving to GitHub issues would increase contributions? I looked around a bit and the only related data I could find was the 2023 Stack Overflow Developer Survey [2] which rates Jira adoption/use pretty high. For what it's worth, there are big, popular projects at Apache which continue to use Jira. > the risk of migrating is more to lose some metadata Losing metadata is not necessarily trivial so it's worth clarifying what metadata is at risk of being lost. I'm not terribly familiar with GitHub Issues. I've reporting issues using it, but I haven't managed a project that used it. Are there features that Jira has and GitHub Issues doesn't? For example, can you perform bulk edits in GitHub Issues? Can you vote on issues? Is there an API to access issue data? If later we wanted to migrate from GitHub Issues to another platform would we be able to access all our data? All these questions may have been answered during migrations for other projects. Do we have a list of which projects have migrated? If so, I will comb through their mailing lists and educate myself. For what it's worth, the discussion on the Shiro dev list was pretty short. > the migration plan is pretty simple, we already have the tooling almost there with INFRA The plan may be simple, but it's still not clear what the plan actually is. If the tooling is "almost there" then what's there an what isn't? Would the plan be to make all the Jira projects read-only and migrate open issues? If so, do all the existing comments on the open issues get migrated? To be clear, I'm not saying we *shouldn't* migrate. It's just that the details aren't clear so I can't make an informed decision yet. Justin [1] https://activemq.apache.org/issues [2] https://survey.stackoverflow.co/2023/#most-popular-technologies-office-stack-async On Mon, Oct 16, 2023 at 12:26 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Justin, > > As we have two components on Jira (one for ActiveMQ, one for Artemis), > I proposed "only" for ActiveMQ. > > The general idea is to use a more modern approach for ActiveMQ: > - not need to request a specific Jira account, just use github > - increase our contributors as the "new" comers are more familiar with > GH ecosystem (outside of Apache) > - the risk of migrating is more to lose some metadata (even if it > didn't happen when migrating shiro or ops4j) > - the migration plan is pretty simple, we already have the tooling > almost there with INFRA > > Regards > JB > > On Mon, Oct 16, 2023 at 6:28 PM Justin Bertram <jbert...@apache.org> > wrote: > > > > It may be better to break this up into separate [DISCUSS] threads - one > for > > Apache Jenkins and GitHub Actions and one for Apache Jira and GitHub > Issues. > > > > In any event, it would be good to get clear details on a few different > > points: > > > > - What specifically are the problems with the existing solution? > > - How are those problems addressed by the proposed solution? Are there > > additional features in the proposed solution that will enable new > > opportunities that don't currently exist? > > - What are the risks of migrating? > > - What is the migration plan? > > > > Once these details are clear we will be able to make an informed decision > > about what action we should take. > > > > Lastly, I think these issues should be considered across ActiveMQ as a > > whole and not just for any individual component. I believe that having > > different ways of doing the same thing for different components on the > same > > project is going to be confusing and frustrating for users and developers > > alike. > > > > > > Justin > > > > On Fri, Oct 13, 2023 at 11:13 AM Jean-Baptiste Onofré <j...@nanthrax.net> > > wrote: > > > > > Hi guys, > > > > > > Even if we are pretty busy and focused on ActiveMQ 6.0.0 release > > > preparation (as said in another email, I should be able to submit the > > > release to vote next week), I think we can anticipate a little the > > > future of ActiveMQ. > > > ActiveMQ 6.0.0 is a major milestone for the project, heading to a more > > > modern approach (I started a PoC to remove Spring dep and using SPI > > > like approach at broker side, I will keep you posted about that) for > > > the codebase, website, and our developer experience. > > > > > > I would like to discuss: > > > 1. Moving from Apache Jenkins to GitHub Actions, using multiple > > > workflows, more decoupled, with potentially more "executors" to build > > > and leveraging GitHub Actions "modules". > > > 2. Moving from Apache Jira to GitHub Issues. Several Apache projects > > > already use GitHub Issues. At OPS4J we also migrated from Jira to GH > > > Issues. We were able to import everything from Jira without losing > > > data. I think it would also be a good opportunity to do some cleanup, > > > maybe starting with only tickets for 6.x. > > > > > > Thoughts ? > > > > > > Regards > > > JB > > > > > > > >
