On Wed, 3 Apr 2024 at 21:14, Matt Pavlovich <mattr...@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 <jbert...@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 >
