Re: Fwd: [DISCUSS] Switch to GitHub issues

[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.


Author of migrated issues:

I documented all my steps in a separate document[2].



-
Sandra

[1] https://github.com/support-and-care/mvn-issues-migration-test/issues

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? 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] The next step will be to test the splitting of a Jira project into many repositories. [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.





Migration result can be found here [3]



-
Sandra

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]. I started a How-to Guide that documents the configuration steps for the migration [4] [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].



Slawomir [4])

Next step for me is, to test the label mapping.

-
Sandra

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 [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 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:

I collected it as issues in the migration tool repository [1], so I can go through the issues step-by-step.

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:

- 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

- change application.properties to Maven Clean Plugin JIRA Project metadata

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:

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


enough to give it a trial.


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 asked on other channels, how Spring migrated their Jira issues. I got I reviewed the code a little, and it appears that the code is generic I will invest some time to do a dry run and share my experience with it.

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:


issue in only one location.


of the backlog.


the Spring Team if they could tell more about how they did it.


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:

Spring's approach has a benefit. As a user, I need only search for an But I also understand Michael's point, that it is a chance for a cleanup Regardless of whether all issues should be migrated or not, I could ask 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

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.


écrit :

Le ven. 22 nov. 2024 à 17:28, Arnaud Héritier <aherit...@gmail.com> a

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...


wrote:

On Fri, Nov 22, 2024 at 12:17 PM Michael Osipov <micha...@apache.org>

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

OpenPGP_signature.asc
Description: OpenPGP digital signature