-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider joining fast-pack org? #9
Comments
I support this. |
hey folks, sincere apologies. I got this during vacation and forgot about it after. Yes I'd be happy to move it. Please tell me what needs to be done. |
I think the simplest way is to add me as an admin to your project, and I will move it, and give you access? |
Done |
Thx! One more thing before i move it - how should we call it (repo name)? @lemire you might have some thoughts on this... Some ideas:
|
I recommend using the Go naming practices: Keep package names short, preferably one word or a very short phrase. |
sure, but the github repo name should not confuse people either - i.e. someone looking through the list of repos shouldn't be confused about the content of the |
Right. But taking into account that the name will be prefixed by fast-pack. I think that including 'go' or 'Go' in the name of a Go package goes against the Go naming practice. Please see the following organization where one package is a Go package: https://github.com/RoaringBitmap :-) |
I must be getting confused already :) Is this a requirement for the git repo to have the same name as the go package? |
P.S. Note that in Rust, it is usually the same convention - the git repo may have an |
The typical usage is like so... import "github.com/fast-pack/nameofrepo"
...
nameofrepo.FunctionFromRepo You do not include the word 'go' in the repo (usually). |
(Note that I am not telling anyone how to name it, I am just stating what the usage is.) |
@lemire thx for the explanation, makes sense. Are you ok to preserve the name as encoding in the new org, or should it be called |
I am neutral but fastpfor won't work because there is FastPFor and I do not think GitHub will allow it. Grok suggests the following names:
|
Recently @lemire, author of the core fastpfor algorithm, transferred all his code to the new github org fast-pack. Would it make sense to move this project to that org too, so that all implementations can be kept closer together and maintained by a community? Current project admins will continue being admins after the transfer, and we could automate publishing to the package registry. Thx!
The text was updated successfully, but these errors were encountered: