fasthttp icon indicating copy to clipboard operation
fasthttp copied to clipboard

Ever considered migrating fasthttp into an organization?

Open panjf2000 opened this issue 4 years ago ā€¢ 15 comments

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~

panjf2000 avatar Oct 28 '19 10:10 panjf2000

This is something only @valyala can answer as he's the only one that can do this.

erikdubbelboer avatar Oct 28 '19 11:10 erikdubbelboer

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.

panjf2000 avatar Oct 30 '19 10:10 panjf2000

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 avatar Oct 30 '19 10:10 valyala

@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~ šŸ˜

panjf2000 avatar Oct 30 '19 11:10 panjf2000

@valyala So, Do you have other concerns about the migration?

panjf2000 avatar Oct 31 '19 09:10 panjf2000

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 avatar Oct 31 '19 10:10 valyala

@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 avatar Oct 31 '19 10:10 panjf2000

@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.

kirillDanshin avatar Oct 31 '19 14:10 kirillDanshin

Wow, that's great! Good luck with that and feel free to reach me when you need a hand.

panjf2000 avatar Oct 31 '19 14:10 panjf2000

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?

erikdubbelboer avatar Nov 03 '19 19:11 erikdubbelboer

@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.

tsingson avatar Nov 03 '19 20:11 tsingson

@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

kirillDanshin avatar Nov 05 '19 14:11 kirillDanshin

@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.

tsingson avatar Nov 05 '19 19:11 tsingson

Any updates regarding the migration, do you guys need help?

Fenny avatar Dec 18 '19 00:12 Fenny

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.

dolmen avatar Feb 21 '20 13:02 dolmen