On Fri, 3 Jan 2025 at 12:33, Sandra Parsick 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
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 time
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 statu
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].
Migrati
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
On average it would only be between one and two searches. And since in most
cases you'd probably know what you're looking for you'd know whether it was
logged before 2025, i.e. it's still on Jira.
Having been through a ticket system migration - in my humble opinion your
concerns are exaggerated.
De
On Thu, 12 Dec 2024 at 13:21, Elliotte Rusty Harold wrote:
>
> On Thu, Dec 12, 2024 at 9:15 AM Christoph Läubrich
> wrote:
> >
> > I just wanted to note with Eclipse moved form Bugzilla > Github it was
> > done the following way:
> >
> > 1. We have had a script adding a comment to each open issu
On Thu, Dec 12, 2024 at 9:15 AM Christoph Läubrich wrote:
>
> I just wanted to note with Eclipse moved form Bugzilla > Github it was
> done the following way:
>
> 1. We have had a script adding a comment to each open issue in Bugzilla
> like this [1]
> 2. Then each developer that finds an issue im
Yes, make sense - also +1
Sylwester
czw., 12 gru 2024, 11:50 użytkownik Guillaume Nodet
napisał:
> I'm also +1 on this way forward.
>
> Le jeu. 12 déc. 2024 à 10:58, Slawomir Jaranowski
> a écrit :
>
> > Hi,
> >
> > On Thu, 12 Dec 2024 at 10:15, Christoph Läubrich
> > wrote:
> > >
> > > I jus
I'm also +1 on this way forward.
Le jeu. 12 déc. 2024 à 10:58, Slawomir Jaranowski
a écrit :
> Hi,
>
> On Thu, 12 Dec 2024 at 10:15, Christoph Läubrich
> wrote:
> >
> > I just wanted to note with Eclipse moved form Bugzilla > Github it was
> > done the following way:
> >
> > 1. We have had a sc
Hi,
On Thu, 12 Dec 2024 at 10:15, Christoph Läubrich wrote:
>
> I just wanted to note with Eclipse moved form Bugzilla > Github it was
> done the following way:
>
> 1. We have had a script adding a comment to each open issue in Bugzilla
> like this [1]
> 2. Then each developer that finds an issue
I just wanted to note with Eclipse moved form Bugzilla > Github it was
done the following way:
1. We have had a script adding a comment to each open issue in Bugzilla
like this [1]
2. Then each developer that finds an issue important enough has migrated
it manually with a link to the old.
3.
Agree too.
We can leave them open in Jira with a comment including the link to
the GH issue.
And if the people involved in the issue are really still interested
(few issues might be already fixed but we haven;t done triage because
it's too much work) they can participate in the GH issue.
Then we ca
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,
Moving would exactly make things faster. This thread diverged quite a
bit, but AFAIR the opener of this thread (or the other mail referenced
by opener of this thread) is exactly about problems _with_ JIRA.
And I also say leave them opened (migrate, leave them as they were
left in JIRA). Not to clo
Non PMC committees certainly can close jira issues. I do this all the time.
Also if we want to conserve volunteer time we should not spend time moving
to GitHub. That’s extra work compared to simply continuing with jira.
Leaving a bug open costs nothing until someone is ready to address it.
On We
Are you all sure this is how _an open source project having
volunteers-only is supposed to work?_ (maybe better as: "spend it's
scarce resources"?)
As if we'd all be in some company, working on some company product,
then yes, I agree wholeheartedly, this is "how things should be done".
But in rea
On 11/12/2024 12:29, Elliotte Rusty Harold wrote:
On Tue, Dec 10, 2024 at 5:10 PM Slawomir Jaranowski
wrote:
On Tue, 10 Dec 2024 at 17:42, Sylwester Lachiewicz
wrote:
Michale proposed closing all issues that have not been active for more
than 3 years, so there will be less to maintain/migra
Le 2024-12-11 12:29, Elliotte Rusty Harold a écrit :
Please press the button. However, this needs to be done issue by
issue, not as a bulk close of all issues older than some arbitrary
date.
+1 to this.
Ideally, even closed issues should be migrated to make it possible to
search for past val
On Tue, Dec 10, 2024 at 5:10 PM Slawomir Jaranowski
wrote:
>
> On Tue, 10 Dec 2024 at 17:42, Sylwester Lachiewicz
> 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 dur
Hi,
Thanks for testing it.
Some comments inline.
On Wed, 11 Dec 2024 at 02:22, Sandra Parsick 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,
>
On Tue, 10 Dec 2024 at 17:42, Sylwester Lachiewicz
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 poin
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 remembe
Sandra,
This is cool and looks good!
Thanks
T
On Tue, Dec 10, 2024 at 5:22 PM Sandra Parsick 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,
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 pro
On Fri, 6 Dec 2024 at 14:41, Sandra Parsick 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-iss
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 cod
On Wed, 4 Dec 2024 at 15:16, Elliotte Rusty Harold wrote:
>
> On Wed, Dec 4, 2024 at 7:36 AM Sandra Parsick wrote:
>
> > But I also understand Michael's point, that it is a chance for a cleanup
> > of the backlog.
>
> There is only one good way to clean up a backlog: read each and every
> issue a
On Wed, Dec 4, 2024 at 7:36 AM Sandra Parsick wrote:
> But I also understand Michael's point, that it is a chance for a cleanup
> of the backlog.
There is only one good way to clean up a backlog: read each and every
issue and triage it as needed with human intelligence. Bulk "cleanups"
are like
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 a
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 a
écrit :
> I know spring teams did such move in the past
> ref:
>
> https://spring.io/blog/2019/01/15/spring-
Le ven. 22 nov. 2024 à 12:17, Michael Osipov a écrit :
> I'd like to complete the cleanup, as dicussed earlier, end of this year.
> This will give us a leaner migration base.
>
>
That's only relevant for #1., isn't it ?
I don't think the JIRA instance is going to go away anytime soon, so I
don't
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 wrote:
> I'd like to complete the cleanup, as dicussed earlier
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
34 matches
Mail list logo
