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
> On 14. Dec 2024, at 18:16, Slawomir Jaranowski wrote:
>
> On Fri, 13 Dec 2024 at 12:12, Gerd Aschemann wrote:
>>
>> I see some drawbacks
>>
>> Before opening a new issue, I would like to search for similar issues (and
>> in particular if there are already solutions, workarcounds, more inf
Hi,
thank you for your summary, which contains every argument I think.
I'm with you and ask for a vote. We all know by the req. Java version
discussion where this will lead if we don't do this (seenoevil)
Am 15.12.2024 um 19:11 schrieb Slawomir Jaranowski:
Hi,
I try summary our discussion a
Hi,
I try summary our discussion about Switch issues to GitHub, so:
At beginning we have a propositions:
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
On Fri, 13 Dec 2024 at 12:12, Gerd Aschemann wrote:
>
> I see some drawbacks
>
> Before opening a new issue, I would like to search for similar issues (and in
> particular if there are already solutions, workarcounds, more information
> about the environment etc.). Where should I search? First d
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
I see some drawbacks
Before opening a new issue, I would like to search for similar issues (and in
particular if there are already solutions, workarcounds, more information about
the environment etc.). Where should I search? First du a Jira search, then a
GitHub search?
If I find something in
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 Mon, 9 Dec 2024 at 18:11, Richard Eckart de Castilho wrote:
>
> How about generating the changelog from the PRs themselves?
>
> https://github.com/apache/uima-parent-pom/blob/main/pom.xml#L1002-L1071
>
It can be next discussion how to technically generate release notes -
in many Maven project
I do agree.
The real work is doing some triage between sections such as: major changes,
bug fixes, dependency updates, build related stuff.
Basically, listing most important things at the beginning, and minor things
at the end on the GitHub release page.
GitHub does a nice thing at generating a sk
How about generating the changelog from the PRs themselves?
https://github.com/apache/uima-parent-pom/blob/main/pom.xml#L1002-L1071
-- Richard
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands,
On Sun, 8 Dec 2024 at 23:03, Elliotte Rusty Harold wrote:
>
> On Sun, Dec 8, 2024 at 9:47 PM Slawomir Jaranowski
> wrote:
> >
> > Hi,
> >
> > I see that more and more PR are not connected to Jira issues ...
> > So we simply take a decision and formally accept what we do
> >
>
> I think that might
tldr; when every JIra issue goes into the release notes, PRs that
don't belong in the release notes should not have Jira issues.
On Sun, Dec 8, 2024 at 10:11 PM Guillaume Nodet wrote:
>
> Le dim. 8 déc. 2024 à 23:03, Elliotte Rusty Harold a
> écrit :
>
> > On Sun, Dec 8, 2024 at 9:47 PM Slawomir
Le dim. 8 déc. 2024 à 23:03, Elliotte Rusty Harold a
écrit :
> On Sun, Dec 8, 2024 at 9:47 PM Slawomir Jaranowski
> wrote:
> >
> > Hi,
> >
> > I see that more and more PR are not connected to Jira issues ...
> > So we simply take a decision and formally accept what we do
> >
>
> I think that mig
On Sun, Dec 8, 2024 at 9:47 PM Slawomir Jaranowski
wrote:
>
> Hi,
>
> I see that more and more PR are not connected to Jira issues ...
> So we simply take a decision and formally accept what we do
>
I think that might be simply related to what the PRs do. Accrual bug
fix and new feature PRs are
Hi,
I see that more and more PR are not connected to Jira issues ...
So we simply take a decision and formally accept what we do
On Sun, 8 Dec 2024 at 11:27, Gerd Aschemann wrote:
>
> For the sake of completeness: I asked Chris Dutz whether he was aware of
> other ASF projects moving from Jira
For the sake of completeness: I asked Chris Dutz whether he was aware of other
ASF projects moving from Jira to GH issues.
* He performed such migration for the PLC4X project (but didn’t leave any tools
to automate that?). Here is a sample for a migrated issue:
https://github.com/apache/plc4x/i
Lets start discuss about convention
https://github.com/apache/maven-site/pull/588
On Wed, 4 Dec 2024 at 19:45, Slawomir Jaranowski wrote:
>
> Hi,
>
> I'm for #2
> - simply add issues to GitHub, disable the creation of new issues in jira.
> - I know that we have many projects ... but we should do
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
Hi,
I'm for #2
- simply add issues to GitHub, disable the creation of new issues in jira.
- I know that we have many projects ... but we should do it one by one
- if project contains not many open issues we can make it read-only at all
we also need a conventions for GitHub issues like is for Jira
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
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 slowl
51 matches
Mail list logo
