I'm playing around with the label mapping.The migration tool has a feature, where you can configure a direct mapping from Jira issue type to Github labels [1].
Furthermore, you can implement an IssueProcessor, where you can implement a mapping based on more context information [2].
Migration result can be found here [3]I started a How-to Guide that documents the configuration steps for the migration [4]
- Sandra[1] https://github.com/support-and-care/jira-to-gh-issues/blob/6152e24db28730c7c3714d2ea26ed29a5b194d3a/src/main/java/io/pivotal/migration/MCleanMigrationConfig.java#L47 [2] https://github.com/support-and-care/jira-to-gh-issues/blob/6152e24db28730c7c3714d2ea26ed29a5b194d3a/src/main/java/io/pivotal/migration/MCleanMigrationConfig.java#L63
[3] https://github.com/support-and-care/mvn-issues-migration-test/issues[4] https://raw.githubusercontent.com/support-and-care/jira-to-gh-issues/refs/heads/master/README.adoc
Am 14.12.24 um 09:07 schrieb Sandra Parsick:
I tested the author mapping of the Spring migration tool. You have to maintain a properties file for the mapping [1].Mapping means that the original author is mentioned in the GH issue comment (see sample [2]). Furthermore, I started with a first draft of mapping (the base was the Jira project of Maven Clean Plugin). I don't know if every mapping is correct, so please check it. If you miss a mapping, please open a PR.As already Sylwester comments in an issue [3], we need a 'service account' for the migration. The next good point is that bot generated comments on jira could be ignored (see also issue bySlawomir [4]) Next step for me is, to test the label mapping. - Sandra[1] https://raw.githubusercontent.com/support-and-care/jira-to-gh- issues/refs/heads/master/src/main/resources/jira-to-github-users.properties [2] https://github.com/support-and-care/mvn-issues-migration-test/ issues/120[3] https://github.com/support-and-care/jira-to-gh-issues/issues/7 [4] https://github.com/support-and-care/jira-to-gh-issues/issues/6 Am 12.12.24 um 07:37 schrieb Sandra Parsick:Thanks for the feedback.I collected it as issues in the migration tool repository [1], so I can go through the issues step-by-step.I will inform you about my progress. Sandra [1] https://github.com/support-and-care/jira-to-gh-issues/issues Am 11.12.24 um 03:00 schrieb Olivier Lamy:Hi, Thanks for testing it. Some comments inline.On Wed, 11 Dec 2024 at 02:22, Sandra Parsick <spars...@web.de.invalid> wrote:IMHO, the task of manual checking of the issues is independent of the issue location. As I said, from a user perspective, it is comfortable to have one location to search for issues, Nevertheless, I give the spring migration tool a trial and did a test run against maven clean plugin Jira project [1]. I have to make small code changes: - create repository in organization is another REST API than create repository in a user space - Apache Jira has a path prefix in the URL(https://issues.apache.org/jira). I have to hard-code this fact in the code.Another steps, I did:- change application.properties to Maven Clean Plugin JIRA Project metadata- add Application context Configuration for Maven Clean Plugin (needed for label mapping etc) All changes can be found in this repository [2] Next steps, I want to try: - Label Mapping - Author mappingWill we probably need to limit it to dev folks? Maybe after each Jira issue migrated, we could add a comment with a link to the created GH issue so non-mapped users can follow the issue in the new location?- It is possible to migrate the release notes from JIRA to GitHubnot sure we need this as we already have some releases there. Except if you can check the existing ones and create only missing release notes. Other than that no real need (gh tool have some tools for this- Some JIRA projects should be separate to many GitHub repositories.yup, shared components will be the problem, and we might split depending on the component field.The migration results can be found here [3].nice!Happy to read some feedback from you - Sandra [1] https://issues.apache.org/jira/projects/MCLEAN [2] https://github.com/support-and-care/jira-to-gh-issues[3] https://github.com/support-and-care/mvn-issues-migration-test/ issuesAm 07.12.24 um 18:04 schrieb Slawomir Jaranowski:On Fri, 6 Dec 2024 at 14:41, Sandra Parsick <spars...@web.de.invalid> wrote:I asked on other channels, how Spring migrated their Jira issues. I gota link to their migration tool: https://github.com/rstoyanchev/jira-to-gh-issues An updated version can be found here: https://github.com/rwinch/jira-to-gh-issues I reviewed the code a little, and it appears that the code is generic enough to give it a trial.I will invest some time to do a dry run and share my experience with it.Another idea: Maven Tycho project also moved from Bugzilla to Github issue. The "migration" was set Bugzilla project read only and only issues were moved to Github which was actively in work.I'm not sure if we need to migrate all issues without manual checking ... We will have the same mess as now.Sandra Am 04.12.24 um 08:36 schrieb Sandra Parsick:My 2 cent from a user perspective:Spring's approach has a benefit. As a user, I need only search for anissue in only one location.But I also understand Michael's point, that it is a chance for a cleanupof the backlog.Regardless of whether all issues should be migrated or not, I could askthe Spring Team if they could tell more about how they did it.Maven Support and Care has an epic about Backlog Grooming [1] and IMHO the migration from Jira to Github issue could be a good first task inthis epic (of course, after a decision about the How). Sandra [1] https://github.com/OpenElements/maven-support-care/issues/42 Am 25.11.24 um 17:36 schrieb Guillaume Nodet:They seem to have migrated the issues from JIRA to GitHub. That would be#1 option, but I'm not sure if we need to go into that direction.Le ven. 22 nov. 2024 à 17:28, Arnaud Héritier <aherit...@gmail.com> aécrit :I know spring teams did such move in the past ref:https://spring.io/blog/2019/01/15/spring-framework-s-migration- from-jira-to-github-issues But I didn't see anything easily reusable...On Fri, Nov 22, 2024 at 12:17 PM Michael Osipov <micha...@apache.org>wrote:I'd like to complete the cleanup, as dicussed earlier, end of thisyear. This will give us a leaner migration base. On 2024/11/22 11:03:09 Guillaume Nodet wrote:Following the discussion that happened some time ago about switching toGHissues... I think we have several options: 1/ try to migrate issues and make JIRA read only2/ make all our JIRA projects unable to create new issues and newissueswould be raised on GH 3/ do not change JIRA but slowly switch to GH#1 looks not feasible, so I rule it out, unless someone knows abouttools,but I don't really see how we could recreate history...#2 would simply require a switch that could be easily requested toINFRA,but until we have made changes to all projects on github, it could be problematic as JIRA would be read-only while some projects may nothave issues enabled yetThe reason for #3 would be to migrate projects not all in one shot.Allprojects use the same permission scheme in JIRA. I think changing the scheme would require JIRA administrator privileges, so I don't thinkanyPMC member can do that easily. However, I know some projects whichhavedone such migration and used JIRA and GH in parallel. I.e. the sourceforrelease notes would be switched to GH and issues would be either GHissuesor JIRA issues. This is the least disrupting option. At some point,wecan decide to go to #2. Thoughts ? -- ------------------------ Guillaume Nodet -- ------------------------ Guillaume Nodet--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org-- Arnaud Héritier Twitter/GitHub/... : aheritier--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
OpenPGP_signature.asc
Description: OpenPGP digital signature
