On Tue, 10 Dec 2024 at 17:42, Sylwester Lachiewicz <slachiew...@gmail.com> wrote: > > Michale proposed closing all issues that have not been active for more > than 3 years, so there will be less to maintain/migrate.
Maybe we can limit the age during import. Maybe we should make a decision for each project. > > 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. probably draft GH release note is visible for committers ... so it is my proposition to use a milestone, which is visible for all. > > > 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 > > > > -- Sławomir Jaranowski --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
