You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Sandra Parsick <sp...@web.de.INVALID> on 2025/01/03 11:33:18 UTC
Re: Fwd: [DISCUSS] Switch to GitHub issues
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.
-
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
>>>>> <sp...@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
>>>>>>> <sp...@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
>>>>>>>>>> <ah...@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
>>>>>>>>>>> <mi...@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-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Arnaud Héritier
>>>>>>>>>>> Twitter/GitHub/... : aheritier
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>
>>
>
Re: Fwd: [DISCUSS] Switch to GitHub issues
Posted by Slawomir Jaranowski <s....@gmail.com>.
On Fri, 3 Jan 2025 at 12:33, Sandra Parsick <sp...@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
> >>>>> <sp...@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
> >>>>>>> <sp...@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
> >>>>>>>>>> <ah...@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
> >>>>>>>>>>> <mi...@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-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Arnaud Héritier
> >>>>>>>>>>> Twitter/GitHub/... : aheritier
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>
> >>>
> >>
> >
>
--
Sławomir Jaranowski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org