Open evandrocoan opened 6 years ago
Huh, interesting. A couple questions though:
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.
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.
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.
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?
upstream -> many forks
can be migrated by creating these links on the forker's backstroke panel with activated 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:
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.
Continuing: https://github.com/backstrokeapp/server/issues/84#issuecomment-349962514 Backstroke-bot has been flagged.
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
oruser_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 asupsteam_name/repository_name
should be more than enough.