> Correct, it's two "isolated" Jira spaces. We have four distinct Jira projects: - https://issues.apache.org/jira/projects/AMQ - https://issues.apache.org/jira/projects/ARTEMIS - https://issues.apache.org/jira/projects/AMQNET - https://issues.apache.org/jira/projects/AMQCPP
We also have 21 Git repos [1] with mirrors on GitHub: - activemq - activemq-activeio - activemq-apollo (archived) - activemq-artemis - activemq-artemis-native - activemq-cli-tools - activemq-cpp - activemq-nms-amqp - activemq-nms-api - activemq-nms-ems - activemq-nms-msmq - activemq-nms-openwire - activemq-nms-openwire-generator - activemq-nms-stomp - activemq-nms-xms - activemq-nms-zmq - activemq-openwire - activemq-protobuf - activemq-stomp - activemq-web - activemq-website As noted previously, those 4 Jira projects would be set to read-only and any open/unresolved issues would be migrated to GitHub Issues. Aside from activemq-apollo (which is archived), would each of these repos have their own GitHub Issues integration? > If you think it would make more sense to start a discussion about having Artemis as TLP... I don't think it would make more sense at this point. > I strongly believe that we could increase our contributors (especially newcomers) thanks to GH as people are familiar with it. Did the other projects which migrated to GitHub Issues do so to increase their contributions? If so, was it effective? If we had *no* presence on GitHub I would 100% agree that putting our repos there would increase contributions due to widespread familiarity with the Git integration it offers. It's just not clear to me that GitHub *Issues* itself would provide the same kind of benefit. It's worth noting that currently there's nothing stopping anybody from sending a PR to any of our repos on GitHub. Is there something specific about adopting GitHub Issues in particular (i.e. not GitHub in general) that you think will increase contributions? > In the past, we moved from CVS to SVN and from SVN to Git, for the exact same reason: features and "modern" approach. We're talking about issue management and not source control, though, right? Has ActiveMQ ever changed issue management? In my opinion, Git is a *huge* upgrade over SVN. Migrating from Jira to GitHub Issues seems more like a lateral move than an upgrade at this point. I asked previously if there were additional features in GitHub Issues that will enable new opportunities that don't currently exist in Jira, but I've not seen an explanation of any such features. > Non developers can create a GH account anyway, I don't see the issue here. This isn't an issue, per se. However, if the argument is that having to create a Jira account is bad then how is having to create a GitHub account any better? And folks will still have to subscribe to the users mailing list to ask questions or get help with diagnosing an issue unless we also start using GitHub Discussions. > Yes, all will be migrated: issues, releases, comments. For issues which were open/unresolved before the migration will there be clear links on the old Jira to the new GitHub Issue? Are you working with anybody specific from Apache infra? Perhaps they could hop on this thread and provide an overview of the process. Or is there documentation on the process you've been referencing? For what it's worth, asf.yml [2] supports "autolink_jira" which makes any Jira ID in commit messages, etc. on GitHub into a link to the actual Jira. Along with the other "jira_options" (e.g. "link") there can be pretty tight integration between Jira and GitHub. This has been very helpful in ActiveMQ Artemis to reduce the effort of switching between GitHub and Jira (something a few folks have mentioned in this thread), but it doesn't appear that this is being used in any other ActiveMQ repo. Again, I'm not saying we shouldn't move. It's just not clear to me yet why we should. Justin [1] https://gitbox.apache.org/repos/asf#activemq [2] https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features On Tue, Oct 17, 2023 at 1:13 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Justin > > On Mon, Oct 16, 2023 at 10:48 PM Justin Bertram <jbert...@apache.org> > wrote: > > > > > 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]. > > Correct, it's two "isolated" Jira spaces. > Some projects have components for subprojects (Karaf for instance, > partly Camel), some projects have GitHub issues (camel-quarkus, > iceberg), some projects moved from Jira to GH Issues (Shiro). > IMHO, having https://github.com/apache/activemq and > https://github.com/apache/artemis would be clearer for the community, > each with GH issues. It's similar to what we have today. > > If you think it would make more sense to start a discussion about > having Artemis as TLP, I can start it but it's not the intention (that > said I think we should have this discussion at some point because: > - for me, we have two different communities (from dev and user > standpoint), and user can "move" from ActiveMQ to Artemis as TLP > (similar "move" happens between Kafka and Pulsar, or between Spark and > Flink and Beam) > - we have different roadmap, perspective, release cycle > But again, that's a different discussion, my intention was not to start > this. > > > > > > ...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. > > Good point, if Artemis, CMS, NMS, want to move to GitHub as well, > that's even better. The initial discussion was for ActiveMQ, but happy > to extend to other part of the ActiveMQ umbrella. > > > > > > The general idea is to use a more modern approach... > > > > Can you elaborate on "more modern"? This seems a bit subjective to me. > > It's subjective but backed with facts: a lot of (most of) new Apache > projects/subprojects are using GitHub Issues/Actions. > Some "new" projects started directly with GitHub (Apache Iceberg, > Streampipes, Pulsar, ...), some projects fully moved to GH (Apache > Shiro), some projects moved subprojects to GH (camel-quarkus, camel-k, > ...). > I strongly believe that we could increase our contributors (especially > newcomers) thanks to GH as people are familiar with it. ASF completely > supports GitHub (via asf.yml to control the features we want to use). > In the past, we moved from CVS to SVN and from SVN to Git, for the > exact same reason: features and "modern" approach. > > > > > > 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. > > Spam is fairly well handled on GH. Non developers can create a GH > account anyway, I don't see the issue here. > Devops, admin, etc, can create GH account and it's the approach "* as > code", like admin can manage the repo via asf.yml. > > > > > > 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. > > It depends what projects we are talking, I have a lot of examples of > projects that using GH. > That's true projects are still using Jira, maybe they are > thinking/discussing moving to GH (I know some projects in this case > :)). > > > > > > 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? > > The only feature that I think it's missing if that it's not possible > to have multiple release per issue, but it could mitigate. > It's possible to vote on issues and attach PRs and yes you have API. > You can also have a lot of plugins usable in PRs/Actions (labeler, > dependabot, etc). > I think that, regarding projects using GH (again, large projects like > Beam, Iceberg, etc), we should have everything we need in ActiveMQ (I > don't see anything specific in ActiveMQ compared to other projects). > > > > > If later we wanted to migrate from GitHub Issues to another platform > would > > we be able to access all our data? > > Yes, we can always extract the data, and it can be also dealt by ASF INFRA. > > > > > 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? > > By almost there, I mean that it's there and we can just ask to trigger. > > > > > 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? > > Yes, all will be migrated: issues, releases, comments. > > > > > > > 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. > > Sure, thanks for that. And that's why we are discussing that on the > mailing list :) > > Regards > JB > > > > > > > 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 > > > > > > > > > > > > > > > > > >
