On Fri, 3 Jan 2025 at 12:33, Sandra Parsick <spars...@web.de.invalid> wrote: > > I continued working on the migration tool. > > Splitting Jira Project in several repositories: > I added a JiraIssueFilter so that you can implement a filter based on > issue information, so that only matched issues will be migrated (sample [1]) > > The idea is that you run the migration tool several times with different > context information for the JiraIssueFilter and a different target > repository to split a Jira project to many repositories. > > The result of a test run for the Maven Shared Jira project with the > component maven-verifier can be found here [2]. The migration > configuration can be found here [3]. > > IMHO, all open questions about how to migrate the jira issues > automatically are answered. Do I miss something? > > I offer to do the migration project-by-project, but I need support from > someone who has commit-rights on the target repositories. >
Thanks Sandra for preparing the tool. Now we can choose a project to migrate .... > - > Sandra > > [1] > https://github.com/support-and-care/jira-to-gh-issues/blob/16626a923059edb5a6eee25b67e6d6f330171c98/src/main/java/io/pivotal/migration/MSharedMigrationConfig.java#L93 > [2] > https://github.com/support-and-care/mvn-split-issues-migration-test/issues > [3] > https://github.com/support-and-care/jira-to-gh-issues/blob/master/src/main/java/io/pivotal/migration/MSharedMigrationConfig.java > > > > > > Am 19.12.24 um 14:36 schrieb Sandra Parsick: > > I'd like to share the current status of testing the migration tool. > > > > Label Mapping: > > I resolved a problem with already existing labels in the repository. > > We can map Jira issue directly to Github labels and add a logic to the > > mapping algo based on more context information, > > For me, the current status of the label mapping mechanismen is good > > enough. Do you miss something, that should be tested? > > > > Author of migrated issues: > > I tested how to create a service account in Github, so the author of the > > migrated issues can be a bot. The result of the test [1] > > I documented all my steps in a separate document[2]. > > > > The next step will be to test the splitting of a Jira project into many > > repositories. > > > > - > > Sandra > > > > [1] https://github.com/support-and-care/mvn-issues-migration-test/issues > > [2] https://github.com/support-and-care/jira-to-gh-issues/blob/master/ > > docs/how-to-create-gh-service-account.adoc > > > > > > Am 17.12.24 um 14:51 schrieb Sandra Parsick: > >> 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 by > >>> Slawomir [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 mapping > >>>>> > >>>>> Will 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 GitHub > >>>>> > >>>>> not 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/ > >>>>>> issues > >>>>>> > >>>>>> Am 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 got > >>>>>>>> a 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 an > >>>>>>>>> issue in only one location. > >>>>>>>>> > >>>>>>>>> But I also understand Michael's point, that it is a chance for > >>>>>>>>> a cleanup > >>>>>>>>> of the backlog. > >>>>>>>>> > >>>>>>>>> Regardless of whether all issues should be migrated or not, I > >>>>>>>>> could ask > >>>>>>>>> the 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 in > >>>>>>>>> this 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 this > >>>>>>>>>>>> year. > >>>>>>>>>>>> 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 to > >>>>>>>>>>>> GH > >>>>>>>>>>>>> issues... > >>>>>>>>>>>>> I think we have several options: > >>>>>>>>>>>>> 1/ try to migrate issues and make JIRA read only > >>>>>>>>>>>>> 2/ make all our JIRA projects unable to create new > >>>>>>>>>>>>> issues and new > >>>>>>>>>>>> issues > >>>>>>>>>>>>> would 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 about > >>>>>>>>>>>> tools, > >>>>>>>>>>>>> but I don't really see how we could recreate history... > >>>>>>>>>>>>> > >>>>>>>>>>>>> #2 would simply require a switch that could be easily > >>>>>>>>>>>>> requested to > >>>>>>>>>>> INFRA, > >>>>>>>>>>>>> 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 not > >>>>>>>>>>>>> have > >>>>>>>>>>>>> issues enabled yet > >>>>>>>>>>>>> > >>>>>>>>>>>>> The reason for #3 would be to migrate projects not all in > >>>>>>>>>>>>> one shot. > >>>>>>>>>>> All > >>>>>>>>>>>>> projects use the same permission scheme in JIRA. I think > >>>>>>>>>>>>> changing the > >>>>>>>>>>>>> scheme would require JIRA administrator privileges, so I > >>>>>>>>>>>>> don't think > >>>>>>>>>>> any > >>>>>>>>>>>>> PMC member can do that easily. However, I know some > >>>>>>>>>>>>> projects which > >>>>>>>>>>> have > >>>>>>>>>>>>> done such migration and used JIRA and GH in parallel. I.e. > >>>>>>>>>>>>> the source > >>>>>>>>>>>> for > >>>>>>>>>>>>> release notes would be switched to GH and issues would be > >>>>>>>>>>>>> either GH > >>>>>>>>>>>> issues > >>>>>>>>>>>>> or JIRA issues. This is the least disrupting option. At > >>>>>>>>>>>>> some point, > >>>>>>>>>>> we > >>>>>>>>>>>>> can 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 > >>>>> > >>>> > >>> > >> > > > -- Sławomir Jaranowski --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
