Michale proposed closing all issues that have not been active for more than 3 years, so there will be less to maintain/migrate.
One point to consider is an adjustment to the release procedure, as new releases will be based only on PR (maybe with optional links to Jira). But as far as I can remember, GH release notes in the draft are not visible outside of PMC. S. wt., 10 gru 2024 o 17:26 Tamás Cservenák <ta...@cservenak.net> napisał(a): > Sandra, > > This is cool and looks good! > > Thanks > T > > On Tue, Dec 10, 2024 at 5:22 PM 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 > > - It is possible to migrate the release notes from JIRA to GitHub > > - Some JIRA projects should be separate to many GitHub repositories. > > > > > > The migration results can be found here [3]. > > > > 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 > >
