Replacement for upstream -> forks links creation #85

Activity

1. 1egoman commented on Dec 12, 2017

   

   1egoman

   on Dec 12, 2017

   Collaborator

   More actions

   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.
2. evandrocoan commented on Dec 13, 2017

   

   evandrocoan

   on Dec 13, 2017

   Author

   More actions

   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.