fasthttp
fasthttp copied to clipboard
Ever considered migrating fasthttp into an organization?
Hi @valyala @erikdubbelboer @kirillDanshin
I am wondering whether we ought to migrate fasthttp
into an organization, fasthttp
is widely used and it is definitely going to thrive, so I think it's better to make fasthttp
a formalized open-source project and migrating into an organization could be the first step to do that. I've already seen an organization: fasthttp created by @kirillDanshin and what is the blocker that stops the migration?
BTW, thanks for your efforts in building such a awesome http framework~
This is something only @valyala can answer as he's the only one that can do this.
I think we should try to contact @valyala via either email or another way that is able to reach him directly since he barely stops by fasthttp since 2017.
I'm OK with the migration. The only drawback is that it can break existing codebases with github.com/valyala/fasthttp imports.
The main question is: which problems will the migration solve?
On Wed, Oct 30, 2019, 12:21 Andy Pan [email protected] wrote:
I think we should try to contact @valyala https://github.com/valyala via either email or another way that is able to reach him directly since he barely stops by fasthttp since 2017.
ā You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/valyala/fasthttp/issues/684?email_source=notifications&email_token=AACFGMS3CEKKYGKOOJANONTQRFN3BA5CNFSM4JFYRFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECTUCXA#issuecomment-547832156, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACFGMW25QRQPJRK34ODCJ3QRFN3BANCNFSM4JFYRFMA .
@valyala About breaking existing codebases with old import path, I believe that Github will automatically redirect the old URL to the new one after a repo has been transferred, referenced from Transferring a repository:
All links to the previous repository location are automatically redirected to the new location. When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL. However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL.
As for your second question, I would say transferring to an organization makes a repo more formalized and official, it is also going to reassure the users of fasthttp that it is a strongly reliable open-source project, not just a personal project.
Finally, being in an organization makes it more convenient to gather related projects or derivatives of fasthttp and users are able to use fasthttp with those projects.
That's all my viewpoints about the migration, hope them help, thanks~ š
@valyala So, Do you have other concerns about the migration?
We need to check that nothing breaks after the migration:
- Old go imports
github.com/valyala/fasthttp
should continue working. -
go mod
should seamlessly work with old and new paths (github.com/fasthttp/fasthttp
).
Otherwise fasthttp users will be unhappy with the migration.
@valyala I understand your consideration and totally support the investigation making sure that everything stays the same. So I think the way to verify whether everything still goes well after the migration is that create a test repo A, import it in another repo B and then transfer repo A into an organization to see if repo B still works with the previous import path, right? I could help with it!
I hope the maintainers of fasthttp join to this migration process and help to transfer fasthttp into fasthttp smoothly, so are you capable to do that? @erikdubbelboer @kirillDanshin
@panjf2000 actually, we already have an outline for the migration, and Iām going to ask for some help and additional monitoring @ github support, so we could fix any problems before our users would notice.
Wow, that's great! Good luck with that and feel free to reach me when you need a hand.
We should definitely do a test with a new repo to see if everything works. I remember the https://github.com/sirupsen/logrus/issues/543 fiasco which was only a case change so not even a move to a different location.
@kirillDanshin are you going to do this test or should I?
@valyala About breaking existing codebases with old import path, I believe that Github will automatically redirect the old URL to the new one after a repo has been transferred, referenced from Transferring a repository:
All links to the previous repository location are automatically redirected to the new location. When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL. However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL.
As for your second question, I would say transferring to an organization makes a repo more formalized and official, it is also going to reassure the users of fasthttp that it is a strongly reliable open-source project, not just a personal project.
Finally, being in an organization makes it more convenient to gather related projects or derivatives of fasthttp and users are able to use fasthttp with those projects.
That's all my viewpoints about the migration, hope them help, thanks~ š
the github.com/fasthttp is good, but, keep https://github.com/valyala/fasthttp in long term please.
@erikdubbelboer I'll test it, if you don't mind
@tsingson we plan to move the development to github.com/fasthttp/fasthttp, but keep updating this repo to allow some time for migration
@erikdubbelboer I'll test it, if you don't mind
@tsingson we plan to move the development to github.com/fasthttp/fasthttp, but keep updating this repo to allow some time for migration
tanks @kirillDanshin , and thanks all contributors.
and, please open sponsor channel.
Any updates regarding the migration, do you guys need help?
A package import path migration doesn't bring any benefits. Only pain.
I have suffered the logrus namespace change which the logrus maintainers still poorly manage. Some logrus users still discover the issue now even if the namespace change occured 2.5 years ago.
All package paths below github.com/valyala/fasthttp/
will have to migrate too to avoid end users using mixed versions from a version of the repo at the old location (example: $GOPATH/src/github.com/valyala/fasthttp/fasthttputil
) and the main package from the repo at the new location ($GOPATH/src/github.com/fasthttp/fasthttp
).
grep '"github.com/valyala/fasthttp/' *.go
So migration should only be considered if you also want to cleanup the API which is the only good reason for an import path change.