Ever considered migrating fasthttp into an organization?

[panjf2000]

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~

[erikdubbelboer]

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

[panjf2000]

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.

[valyala]

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 ***@***.***> 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 <#684?email_source=notifications&email_token=AACFGMS3CEKKYGKOOJANONTQRFN3BA5CNFSM4JFYRFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECTUCXA#issuecomment-547832156>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACFGMW25QRQPJRK34ODCJ3QRFN3BANCNFSM4JFYRFMA> .

[panjf2000]

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

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

[valyala]

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.

[panjf2000]

@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

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

[panjf2000]

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

[erikdubbelboer]

We should definitely do a test with a new repo to see if everything works. I remember the sirupsen/logrus#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?

[tsingson]

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

[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

[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

tanks @kirillDanshin , and thanks all contributors.

and, please open sponsor channel.

[Fenny]

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

[dolmen]

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.