Hi Brandon, If we decide to do the work I would vote to either use scripts already made by other projects. Or use this as an opportunity to make our own Jira transforms ;)
Cheers, Hans On 26 October 2022 at 15:30:32, Brandon Jackson ([email protected]) wrote: Hi Hans, Just putting it out there because I have had to live in the world without fantastic JDBC connectors, but you might give https://meltano.com/elt-meltano/ a try. It is based on singer.io taps and they have sources and destinations for github and JIRA where you take extract issues from one and output in another. At a minimum you can extract everything there is on one end and use Hop potentially to shape it before pushing it into github. Or as an alternative, give CDATA drivers a trial run for 14 days and go full on JDBC route getting from one system to another. At least if you can extract everything from JIRA and work with the data, it should make migration easier. I would be happy to lend a hand and could demonstrate extraction or pushing data to or from these systems. Brandon On Wed, Oct 26, 2022 at 2:42 AM Hans Van Akelyen <[email protected]> wrote: > Hi All, > > As discussed in our previous thread we would all like to move to GitHub > Issues. > Now we will have to come up with a plan on how to make this happen… And it > will require a bit of work. > > Unfortunately there is nog magic button that migrates all our issues from > Jira to GH. We will have to create a cut-off point and put our current Jira > project in read-only mode for historical reference. > The good news however is that we are not the first project doing this > migration. If needed and based on our decisions we can ask around with > other projects on how they handled the work. > > I think the 2 major components we have to align on is the WHEN and the > WHAT. > > About the when, we *could* migrate at any time depending on what we decide > for the what. Migration during a running release means we will have to > create release notes based on 2 sources, or copy over the already done > tickets to GH to generate a complete release note report. Switching to GH > Issues directly after a release IMHO seems like the best approach. For the > 2.2 release I think our target should be end of November, no one wants to > make a release during the end of year and it would go by unnoticed by the > masses. > > Now the harder part, the what. We can put our Jira in read-only and migrate > nothing! We would start with a clean slate and would have to re-create the > tickets we are working on manually. This means we will not be taking over > our current backlog and all tickets would have to be reported again. The > advantage is we don’t have to do much work. > The second option is using some tools/scripts (will have to ask around with > other projects) to migrate all open issues to GH Issues. I would still > suggest we first do a cleanup of the backlog (we currently have 760 tickets > in backlog). Even after cleaning up we will still have plenty to do… > The final option, we split the work validate each ticket and manually > migrate/update and add more information. > > For the move to GH Issues, you can also take a look at how Apache Beam and > Apache Airflow are handling things, they have templates and bots to help > with initial triage/labeling of the issues. > > As always, feel free to share ideas/experience/comments! > > Cheers, > Hans >
