Migrating Issues for extracted components

[matt-oakes]

Introduction

Now we are starting to move components from the core repo into the react-native-community repositories, we should also think about migrating the issues. Ideally, we should do it in a way which keeps any discussion which has happened.

The Core of It

We should migrate the issues so we can keep track of any reported issues so we know what improvements need to be made to the components.

To my mind, the goals should be:

• Keep any discussion which previously happened.
• Keep people who subscribed to the previous issue informed about the change of issue location.

Other communities have gone through a similar process in the past. For example, when Fastlane went from separate repositories to a monorepo (ironically the opposite of what RN is doing...) they migrated all opened issues. This is an example of what the old issues and new issues look like after migration. Note that they:

• Kept all of the original comments including images and things like the user's profile picture. This makes the issues pretty easy to read still.
• Commented on the old issue with details about where it has moved to and why.

For reference the code they used for the migration is here:

https://github.com/fastlane/monorepo/blob/master/migrate_issues.rb

Discussion points

• Is this something we need to do?
• Is this a big enough job to require automation?
• How do we identify which issues need to be migrated?
• Do we take this opportunity to migrate issues that were closed due to inactivity, or do we only migrate issues which are currently open?

[cpojer]

• Let's do it!
• I can probably take care of moving things, but somebody will need to tell me which ones to move.
• If you bring valid but closed issues to my attention, I can move them.

[matt-oakes]

Thanks!

I forgot to mention, I found this tool which could help automate it slightly:

https://github.com/google/github-issue-mover

You essentially provide a source and destination and it used the authenticated user to move the issues. I've not tested it, but it might be easier to use that than write something custom.

For the NetInfo module I can see these issues which need migrating:

• NetInfo.isConnected.addEventListener behaves incorrectly facebook/react-native#22966
• NetInfo.isConnected.addEventListener: diverging behaviors on Android and iOS facebook/react-native#22954
• [0.57] - NetInfo methods fail to resolve or reject facebook/react-native#21953
• Multiple fetch request starts to not resolve or reject promise facebook/react-native#21862
• Fetch API breaks when turning network off and on. facebook/react-native#19709
• NetInfo returns true when connected to [WiFi|cellular] but Internet is not reachable facebook/react-native#18368
• NetInfo.isConnected.addEventListener only works in root componentDidMount facebook/react-native#18130
• Headless JS Android -- detachViewFromInstance() prevents Background Tasks if App is closed facebook/react-native#16267

There might be more, but I've not yet gone through the full list of closed issues.

[elicwhite]

I believe you don’t need a tool anymore. GitHub built this feature in: https://help.github.com/articles/transferring-an-issue-to-another-repository/

[matt-oakes]

Cool!

I've I'm reading it correctly it looks like you can only transfer within an organisation, but someone with admin access to both repos will be able to confirm that one way or the other.

[cpojer]

I just checked and it seems like it is not possible to migrate issues across orgs unfortunately. @matt-oakes shall I use the issue mover you posted about instead?

[matt-oakes]

@cpojer Maybe try it with one of the issues and see how it looks. I'm happy with whatever method that you are really 🙂

[kelset]

it seems like it is not possible to migrate issues across orgs unfortunately.

I can double check with the GitHub devs but if I recall correctly you need to be admin level permissions in both repos (source -> destination).

If not, for WebView they approached via creating new issues - cc @Titozzz.

[cpojer]

Just fyi, it seems like we cannot use this app because it would require giving access to the whole facebook GitHub org, including private repos, so we can't authorize it. I'm gonna go ahead for now and move the NetInfo issues manually just so we got those covered.

[cpojer]

@zpao saved me and created a simple script that can do this for us, without having to give access to a third-party tool: https://gist.github.com/zpao/a44889a3dfeda9af24561c631c9f8c03 thank you so so much!

[rafaellincoln]

@matt-oakes Thank you for this proposal!

@cpojer I found these issues, for PushNotificationIOS, which could be migrated too!

• RCTPushNotificationManager does not set alertTitle in UILocalNotification facebook/react-native#14699
• PushNotificationIOS.requestPermissions won't resolve if no event listeners are attached facebook/react-native#13012

Would it be interesting to mark all users, in this issue, that migrated part of the core?

[kelset]

Would it be interesting to mark all users, in this issue, that migrated part of the core?

I think it would be an overkill, a simple comment with the link to the new issue when closing is enough.

[cpojer]

@rafaellincoln just used the new script on these two issues, it works, yay!

[cpojer]

I took care of all the existing components that were split out. If there is something I missed, let me know. I'll also do this for projects that are split out in the future. Closing this issue as it seems resolved.

[radeno]

@cpojer if it helps we can create shared Google sheets document with columns "From Repo", "To Repo", "Issue number" and then export it as CSV and use all data with @zpao script to move it.
Every sheet should be one community repository.

It could saved a lot of time instead do it manually.