Replacement for upstream -> forks links creation

[evandrocoan]

Continuing: #84 (comment) Backstroke-bot has been flagged.

This feature of setup all forks to receive updates from the upstream should not automatically spread pull request through all forks. It should just also be opt-in by the fork users'. But as the fork owner has setup it, the fork users' could accept it. This could be done only by the fork users which already have a backstroke account. Then when they fork a repository which has backstroke setup, this backstroke link is added to the https://app.backstroke.co/#/links page as a disabled link. Then, they can enable it if they want to.

To help them, the users which already have a backstroke account, they could receive a email from backstroke with a link which they can use to enable the link if they want to. Users which do not have a backstroke account, should not receive any email. But when they create a backstroke account, they will already have these links available to be enabled, if they want to.

Instead of allowing the repositories owners to setup a backstroke link for their forks, we can remove this feature completely and change the way how links are created. The new link creation page should just require the url/link or user_name/repository_name to the user fork, then it creates everything only with this information. Just a simple link.

This could be done because you can infer everything backstroke needs just by the link. The repository upstream or downstream can be derived from the GitHub API with the link, and the link name can be by default the upsteam_name/repository_name. The user can change the backstroke link name if the wants to, but why bother? A name as upsteam_name/repository_name should be more than enough.

[1egoman]

Huh, interesting. A couple questions though:

1. How does migration of existing upstream => many fork links work? Are they just removed, and if so, how are the owners of those links notified so that they can figure out alternative plans? In your original comment you had mentioned allowing forks to be "invited" to links, curious what if anything has changed your mind.

2. A feature that I've personally needed and something that I've heard that others need is syncing a repository to an out-of-network repository that shares the same history. Here's a document that I wrote up about it. The backend code is already in place for this change, the last piece was the frontend code. I'm curious how a feature like this would work into your plan.

3. I like the idea of making the name of a link optional - I think most of the time, it's not needed, and it's kinda a remnant of v1.

[evandrocoan]

In your original comment you had mentioned allowing forks to be "invited" to links,

I thought that sending emails to to everyone in the fork can generate too much spam for big repositories like 100.000 forks or smaller like 100 or 1000. This is why I opt to not spend time creating code just to spam more people's email. Perhaps the emails spam filters could start tagging backstroke emails as spam, which would not be nice.

How does migration of existing upstream => many fork links work?

1. The current forks which are active by upstream -> many forks can be migrated by creating these links on the forker's backstroke panel with activated state.
2. The current forks which are not active, can be migrated by creating them on the user account with the deactivated state.

As the existing upstream -> many forks links are currently opt-in by label creation. The label creating feature could be deprecated. And the link activation could be just by opening the user backstroke panel and enabling the link.

To prevent a mess on the user links list, we can split the links into two sections:

1. The first section is for the links which the user manually created.
2. The second section is for the links which were created by the upstream -> many forks feature.

However, does not seem necessary/required as the link creating would be very simple as just pasting the upstream link. The feature upstream -> many forks could be deprecated and the current forks activated by the users should be migrated to their accounts as active links and new users which would like to receive updates from the upstream just need to open their panel and paste the upstream link.

Are they just removed, and if so, how are the owners of those links notified so that they can figure out alternative plans?

Currently, this feature already does not work as they would expect. The user need explicitly take an action of creating and deleting labels in order for the upstream -> many forks feature work. Then there is no difference for them whether their users do the labels creating/deletion magic or just open their backstroke panel and paste the link to the upstream. I think this is more straight forward than doing the label creation deletion.

The backend code is already in place for this change, the last piece was the frontend code. I'm curious how a feature like this would work into your plan.

That feature could not be helped, as there is not way to deducing the upstream or downstream info to create the links. Then on this case the link creation would be just like it is already.