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 > > > > > > > > > > > >
