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

Reply via email to