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
