Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: avatica-go-2.2.0
    • Component/s: avatica-go
    • Labels:
      None

      Description

      Add a client for Avatica written in the Go language (aka "Golang").

      There is one at https://github.com/Boostport/avatica and the author has offered to contribute it.

      The driver is currently somewhat specialized for Phoenix but our goal should be to allow it to work against any Avatica provider (without diminishing its value to Phoenix users).

        Issue Links

          Activity

          Hide
          francischuang Francis Chuang added a comment -

          Julian Hyde

          A few questions:
          1. What is the process for getting the code into the Calcite/Avatica project?
          2. Is it possible to get a separate git repo for this? It makes it easier to import using Go's dependency tools like dep and the package structure would be more idiomatic.

          Show
          francischuang Francis Chuang added a comment - Julian Hyde A few questions: 1. What is the process for getting the code into the Calcite/Avatica project? 2. Is it possible to get a separate git repo for this? It makes it easier to import using Go's dependency tools like dep and the package structure would be more idiomatic.
          Hide
          elserj Josh Elser added a comment -

          2. Is it possible to get a separate git repo for this? It makes it easier to import using Go's dependency tools like dep and the package structure would be more idiomatic.

          Yup

          What is the process for getting the code into the Calcite/Avatica project?

          Essentially, we'll have to follow the IP Clearance process. https://incubator.apache.org/ip-clearance/index.html

          This isn't anything more than some formality in documenting: license compatibility, copyright assignment, and such. Working through the Go dependencies to make sure we follow ASF policies will be the biggest issue

          Show
          elserj Josh Elser added a comment - 2. Is it possible to get a separate git repo for this? It makes it easier to import using Go's dependency tools like dep and the package structure would be more idiomatic. Yup What is the process for getting the code into the Calcite/Avatica project? Essentially, we'll have to follow the IP Clearance process. https://incubator.apache.org/ip-clearance/index.html This isn't anything more than some formality in documenting: license compatibility, copyright assignment, and such. Working through the Go dependencies to make sure we follow ASF policies will be the biggest issue
          Hide
          julianhyde Julian Hyde added a comment -

          Here are the steps to go through the IP clearance process. The steps are:

          1. Vote on dev about accepting the code into the project
          2. Add new IP clearance proposal to http://incubator.apache.org/ip-clearance/
          3. Contributor(s) (i.e. Francis Chuang) execute a software grant document and PMC sends to the ASF secretary
          4. Check that contributor(s) has filed an ICLA with ASF
          5. Once the Software Grant has been acknowledged by the ASF secretary and the ICLAs are on file, start a lazy consensus vote about the IP clearance on general@incubator

          A separate git repo is certainly possible. I can see the benefits. I have a small concern that it might make unified releases of Avatica-Java and Avatica-Go more difficult (if we ever decided to do that).

          Julien Le Dem since you've been through this, do you have any regrets about splitting Parquet into several repositories?

          Show
          julianhyde Julian Hyde added a comment - Here are the steps to go through the IP clearance process . The steps are: Vote on dev about accepting the code into the project Add new IP clearance proposal to http://incubator.apache.org/ip-clearance/ Contributor(s) (i.e. Francis Chuang ) execute a software grant document and PMC sends to the ASF secretary Check that contributor(s) has filed an ICLA with ASF Once the Software Grant has been acknowledged by the ASF secretary and the ICLAs are on file, start a lazy consensus vote about the IP clearance on general@incubator A separate git repo is certainly possible. I can see the benefits. I have a small concern that it might make unified releases of Avatica-Java and Avatica-Go more difficult (if we ever decided to do that). Julien Le Dem since you've been through this, do you have any regrets about splitting Parquet into several repositories?
          Hide
          julianhyde Julian Hyde added a comment -

          Actually, step 0 would be a discussion on dev. Let me start that.

          Show
          julianhyde Julian Hyde added a comment - Actually, step 0 would be a discussion on dev. Let me start that.
          Hide
          francischuang Francis Chuang added a comment - - edited

          For the dependencies:

          Other than Go's standard library, the project also imports the following dependencies directly: https://github.com/Boostport/avatica/blob/master/Gopkg.toml

          The imported dependencies also import further dependencies of their own. The list of ALL dependencies used are in here: https://github.com/Boostport/avatica/blob/master/Gopkg.lock

          Dependencies under the golang.org/x/ namespace are part of the Go project but are considered to be experimental.

          Show
          francischuang Francis Chuang added a comment - - edited For the dependencies: Other than Go's standard library, the project also imports the following dependencies directly: https://github.com/Boostport/avatica/blob/master/Gopkg.toml The imported dependencies also import further dependencies of their own. The list of ALL dependencies used are in here: https://github.com/Boostport/avatica/blob/master/Gopkg.lock Dependencies under the golang.org/x/ namespace are part of the Go project but are considered to be experimental.
          Hide
          julianhyde Julian Hyde added a comment -

          It seems that go-cleanhttp is MPL, which is category b (weak copyleft). We'll have to be careful with that.

          The others are Apache, BSD or MIT, so they're OK.

          Show
          julianhyde Julian Hyde added a comment - It seems that go-cleanhttp is MPL, which is category b (weak copyleft) . We'll have to be careful with that. The others are Apache, BSD or MIT, so they're OK.
          Hide
          francischuang Francis Chuang added a comment -

          go-cleanhttp is a really simple library. All it does is set up the http client with sane defaults: https://github.com/hashicorp/go-cleanhttp/blob/master/cleanhttp.go

          If required, I can remove the dependency on it and initialize the http client manually with those defaults.

          Show
          francischuang Francis Chuang added a comment - go-cleanhttp is a really simple library. All it does is set up the http client with sane defaults: https://github.com/hashicorp/go-cleanhttp/blob/master/cleanhttp.go If required, I can remove the dependency on it and initialize the http client manually with those defaults.
          Hide
          julianhyde Julian Hyde added a comment -

          Shouldn't be necessary. Category b licensed dependencies are OK, as long as we're careful.

          We can deal with this the first release after the code is accepted.

          Show
          julianhyde Julian Hyde added a comment - Shouldn't be necessary. Category b licensed dependencies are OK, as long as we're careful. We can deal with this the first release after the code is accepted.
          Hide
          julianhyde Julian Hyde added a comment -

          OK, starting this process now. Francis Chuang, can you please complete step 3 of the IP clearance template:

          3. A software grant must be provided to the ASF. This grant can either be done by the ASF Corporate CLA (via Schedule B) or the Software Grant Agreement. The completed and signed grant must be emailed to secretary@apache.org

          I suggest that we use the current HEAD, https://github.com/Boostport/avatica/commit/77207918cf826662cb4ea40cfffbfb5cb64bf4a0, the code donation. If you agree, I will create a tar ball and commit it to the incubator drop area.

          I am currently filling out the form and plan to commit it as http://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/calcite-avatica-boostport-go.xml.

          Show
          julianhyde Julian Hyde added a comment - OK, starting this process now. Francis Chuang , can you please complete step 3 of the IP clearance template : 3. A software grant must be provided to the ASF. This grant can either be done by the ASF Corporate CLA (via Schedule B) or the Software Grant Agreement. The completed and signed grant must be emailed to secretary@apache.org I suggest that we use the current HEAD, https://github.com/Boostport/avatica/commit/77207918cf826662cb4ea40cfffbfb5cb64bf4a0 , the code donation. If you agree, I will create a tar ball and commit it to the incubator drop area. I am currently filling out the form and plan to commit it as http://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/calcite-avatica-boostport-go.xml .
          Hide
          francischuang Francis Chuang added a comment -

          Hey Julian Hyde

          Thanks for getting the ball rolling. A corporate CLA for Boostport Pty Ltd was signed in September last year when I was accepted as a committer. An acknowledgement was CC'd to the calcite private list on the 6th of September, 2016. Is this sufficient? If not, I'll fill in the Software Grant Agreement and send that to secretary@apache.org

          Using the current HEAD should be fine.

          Show
          francischuang Francis Chuang added a comment - Hey Julian Hyde Thanks for getting the ball rolling. A corporate CLA for Boostport Pty Ltd was signed in September last year when I was accepted as a committer. An acknowledgement was CC'd to the calcite private list on the 6th of September, 2016. Is this sufficient? If not, I'll fill in the Software Grant Agreement and send that to secretary@apache.org Using the current HEAD should be fine.
          Show
          julianhyde Julian Hyde added a comment - The Boostport CCLA will do fine. (It is present and correct at https://svn.apache.org/repos/private/foundation/officers/cclas.txt .) I have filled out and committed the form: http://incubator.apache.org/ip-clearance/calcite-avatica-go.html It includes a patch http://people.apache.org/~jhyde/boostport-avatica.patch based on https://github.com/Boostport/avatica/commit/77207918cf826662cb4ea40cfffbfb5cb64bf4a0 .
          Hide
          julianhyde Julian Hyde added a comment -

          Josh Elser, I got stuck on one step:

          If the source is referenced by checksum in the grant, commit the canonical tarball for the donated code into the incubator drop area (/repos/asf/incubator/donations) together with a checksum and a detached signature. This will ensure that apache has a legal record of the grant.

          AFAICT, /repos/asf/incubator/donations doesn't exist. Is this a typo in the template? What did you do when you handled previous IP clearance?

          As mentioned above, I put the patch in my home directory. I don't know whether that is sufficient.

          Show
          julianhyde Julian Hyde added a comment - Josh Elser , I got stuck on one step: If the source is referenced by checksum in the grant, commit the canonical tarball for the donated code into the incubator drop area (/repos/asf/incubator/donations) together with a checksum and a detached signature. This will ensure that apache has a legal record of the grant. AFAICT, /repos/asf/incubator/donations doesn't exist. Is this a typo in the template? What did you do when you handled previous IP clearance? As mentioned above, I put the patch in my home directory. I don't know whether that is sufficient.
          Hide
          elserj Josh Elser added a comment - - edited

          AFAICT, /repos/asf/incubator/donations doesn't exist. Is this a typo in the template? What did you do when you handled previous IP clearance?

          Hrm, that's interesting. I don't think I committed the granted codebase to SVN before. Pulling up the old thread, I just hosted it in my ~elserj space on people.a.o ("https://github.com/apache/incubator-slider/pull/3 or http://people.apache.org/~elserj/KOYA-grant.patch" is specifically what I put in the IP clearance XML form). I would say what you've done is sufficient – someone can correct us during the lazy-consensus period if that is incorrect.

          Here's the form I filled out last time if helpful: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/slider-koya.xml

          Show
          elserj Josh Elser added a comment - - edited AFAICT, /repos/asf/incubator/donations doesn't exist. Is this a typo in the template? What did you do when you handled previous IP clearance? Hrm, that's interesting. I don't think I committed the granted codebase to SVN before. Pulling up the old thread, I just hosted it in my ~elserj space on people.a.o ("https://github.com/apache/incubator-slider/pull/3 or http://people.apache.org/~elserj/KOYA-grant.patch " is specifically what I put in the IP clearance XML form). I would say what you've done is sufficient – someone can correct us during the lazy-consensus period if that is incorrect. Here's the form I filled out last time if helpful: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/slider-koya.xml
          Hide
          julianhyde Julian Hyde added a comment -

          Vote is in progress now.

          Francis Chuang, When the vote finishes, what are the next steps? Would you like an empty git repo (into which you can load the latest source) or a repo that is a copy of https://github.com/boostport/avatica?

          Then I think we should make sure files have Apache headers, update documentation, create a release history page, and create a release candidate, update Avatica's web site. What do you think?

          Show
          julianhyde Julian Hyde added a comment - Vote is in progress now. Francis Chuang , When the vote finishes, what are the next steps? Would you like an empty git repo (into which you can load the latest source) or a repo that is a copy of https://github.com/boostport/avatica? Then I think we should make sure files have Apache headers, update documentation, create a release history page, and create a release candidate, update Avatica's web site. What do you think?
          Hide
          francischuang Francis Chuang added a comment -

          Julian Hyde

          Thanks for organizing this! An empty repo is fine, I can push the existing code into the repo. Should I push the existing tags or should we only have the tags for when the code is part of the Apache foundation?

          I agree that the headers docs and other pieces will need to be updated. Is there an official list of things we should do before tagging the first release?

          Show
          francischuang Francis Chuang added a comment - Julian Hyde Thanks for organizing this! An empty repo is fine, I can push the existing code into the repo. Should I push the existing tags or should we only have the tags for when the code is part of the Apache foundation? I agree that the headers docs and other pieces will need to be updated. Is there an official list of things we should do before tagging the first release?
          Hide
          julianhyde Julian Hyde added a comment -

          The vote on general@incubator (thread) has passed (result).

          Show
          julianhyde Julian Hyde added a comment - The vote on general@incubator ( thread ) has passed ( result ).
          Hide
          julianhyde Julian Hyde added a comment -

          Francis Chuang, I see that INFRA-14777 is marked fixed, so there is now a repo. Would you mind creating a pull request for the initial version of the repo? Josh and I will review.

          Show
          julianhyde Julian Hyde added a comment - Francis Chuang , I see that INFRA-14777 is marked fixed, so there is now a repo. Would you mind creating a pull request for the initial version of the repo? Josh and I will review.
          Hide
          francischuang Francis Chuang added a comment -

          Julian HydeShould I push the whole commit history from the old repo, or just the latest commit (without the history)?

          Show
          francischuang Francis Chuang added a comment - Julian Hyde Should I push the whole commit history from the old repo, or just the latest commit (without the history)?
          Hide
          francischuang Francis Chuang added a comment -

          Also, I can't find the avatica-go repo in the Apache org on github.

          Show
          francischuang Francis Chuang added a comment - Also, I can't find the avatica-go repo in the Apache org on github.
          Hide
          elserj Josh Elser added a comment -

          I'm not seeing it either. Maybe INFRA just meant that they fixed the reporeq tool and didn't actually create the repo for you, Julian Hyde?

          I can create it too – I just don't want to cause a race-condition between us

          Show
          elserj Josh Elser added a comment - I'm not seeing it either. Maybe INFRA just meant that they fixed the reporeq tool and didn't actually create the repo for you, Julian Hyde ? I can create it too – I just don't want to cause a race-condition between us
          Hide
          julianhyde Julian Hyde added a comment -

          Sorry, I didn't actually check. I have limited network bandwidth. Josh, Please create it.

          Francis, Up to you whether you push the history or just the latest. Either is fine.

          Show
          julianhyde Julian Hyde added a comment - Sorry, I didn't actually check. I have limited network bandwidth. Josh, Please create it. Francis, Up to you whether you push the history or just the latest. Either is fine.
          Hide
          elserj Josh Elser added a comment -

          The canonical ASF repo is live at https://git-wip-us.apache.org/repos/asf?p=calcite-avatica-go.git

          The Github mirror is still in the process of being created, but should show up here eventually

          Show
          elserj Josh Elser added a comment - The canonical ASF repo is live at https://git-wip-us.apache.org/repos/asf?p=calcite-avatica-go.git The Github mirror is still in the process of being created, but should show up here eventually
          Hide
          francischuang Francis Chuang added a comment - - edited

          Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go on github.

          • The repo is currently empty, so I cannot fork it on GH and use a fork.
          • I created a F21/calcite-avatica-go repo and pushed the initial commit there, but it won't let me open a PR against apache/calcite-avatica-go.

          A few other issues:

          • I currently use Wercker for CI. Can wercker be used on Apache repos?
          • I use goveralls for code coverage reports. Can it be used on Apache repos?
          Show
          francischuang Francis Chuang added a comment - - edited Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go on github. The repo is currently empty, so I cannot fork it on GH and use a fork. I created a F21/calcite-avatica-go repo and pushed the initial commit there, but it won't let me open a PR against apache/calcite-avatica-go. A few other issues: I currently use Wercker for CI. Can wercker be used on Apache repos? I use goveralls for code coverage reports. Can it be used on Apache repos?
          Hide
          elserj Josh Elser added a comment -

          Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go on github.

          Correct. The canonical repository is hosted on git-wip-us.apache.org. The Github "version" is just a copy/mirror for convenience.

          it won't let me open a PR against apache/calcite-avatica-go.

          That does seem like a problem. Let me see what I can do.

          Show
          elserj Josh Elser added a comment - Ok, the repo is now on Github, but I ran into a snag as I am not allowed to push directly to apache/calcite-avatica-go on github. Correct. The canonical repository is hosted on git-wip-us.apache.org. The Github "version" is just a copy/mirror for convenience. it won't let me open a PR against apache/calcite-avatica-go. That does seem like a problem. Let me see what I can do.
          Hide
          elserj Josh Elser added a comment -

          I currently use Wercker for CI. Can wercker be used on Apache repos?
          I use goveralls for code coverage reports. Can it be used on Apache repos?

          Ideally, it would be better to not rely on external systems, but I don't believe there is a reason we cannot use them.

          It would be good to transition to the ASF Jenkins server(s) for CI so that all members of Calcite can improve it.

          For code-coverage, using this as a tool is fine, IMO. There are some tools which may be available at the ASF already, but I'm not sure how they compare WRT features. Is there a non-hosted options that developers could run on their own?

          Show
          elserj Josh Elser added a comment - I currently use Wercker for CI. Can wercker be used on Apache repos? I use goveralls for code coverage reports. Can it be used on Apache repos? Ideally, it would be better to not rely on external systems, but I don't believe there is a reason we cannot use them. It would be good to transition to the ASF Jenkins server(s) for CI so that all members of Calcite can improve it. For code-coverage, using this as a tool is fine, IMO. There are some tools which may be available at the ASF already, but I'm not sure how they compare WRT features. Is there a non-hosted options that developers could run on their own?
          Hide
          elserj Josh Elser added a comment -

          Francis Chuang, I pushed an initial commit that adds a basic LICENSE and NOTICE file to the repository.

          You should be able to create a fork from the apache/calcite-avatica-go repository now. You can create a pull-request, but you would still need to commit it via the canonical repository https://git-wip-us.apache.org/repos/asf/calcite-avatica-go.git

          Typically what I have is multiple remotes set up for a git repository:

          • Origin points to the canonical ASF repository
          • joshelser points to my GH fork of the repository on the apache org on Github

          So, you can git-fetch your changes from your personal GH, merge it into master locally, and then push it to origin (canonical ASF repo).

          Show
          elserj Josh Elser added a comment - Francis Chuang , I pushed an initial commit that adds a basic LICENSE and NOTICE file to the repository. You should be able to create a fork from the apache/calcite-avatica-go repository now. You can create a pull-request, but you would still need to commit it via the canonical repository https://git-wip-us.apache.org/repos/asf/calcite-avatica-go.git Typically what I have is multiple remotes set up for a git repository: Origin points to the canonical ASF repository joshelser points to my GH fork of the repository on the apache org on Github So, you can git-fetch your changes from your personal GH, merge it into master locally, and then push it to origin (canonical ASF repo).
          Hide
          francischuang Francis Chuang added a comment - - edited

          Josh ElserThanks for sorting that out!

          Josh ElserJulian Hyde A PR has been opened on the GH repo to rack the initial commit. There are still a few things to do before it can be merged.

          Regarding tags, should tags from the original repo be pushed? Or should be start a new versioning scheme?

          Show
          francischuang Francis Chuang added a comment - - edited Josh Elser Thanks for sorting that out! Josh Elser Julian Hyde A PR has been opened on the GH repo to rack the initial commit. There are still a few things to do before it can be merged. Regarding tags, should tags from the original repo be pushed? Or should be start a new versioning scheme?
          Hide
          francischuang Francis Chuang added a comment - - edited

          I did some research regarding using Apache's infrastructure for CI and the ASF buildbot. I have some questions regarding how to set this up:

          • What needs to be done to set up CI for the project?
          • Can Apache's Jenkins build PRs submitted on github as well?
          • Jenkins uses a jenkinsfile which is stored in the project repo, but I do not see the jenkinsfile in the calcite or kafka repos. How are builds configured?

          There is a sonarqube instance: https://wiki.apache.org/general/SonarInstance

          Maybe it can provide code coverage, but I think the Go plugin needs to be installed: https://github.com/uartois/sonar-golang

          Ideally, there should be build status and coverage status images that can be embedded in the README.md file.

          Regarding github pushes, I think it may be possible if the repo is hosted on Gitbox: https://gitbox.apache.org

          Show
          francischuang Francis Chuang added a comment - - edited I did some research regarding using Apache's infrastructure for CI and the ASF buildbot. I have some questions regarding how to set this up: What needs to be done to set up CI for the project? Can Apache's Jenkins build PRs submitted on github as well? Jenkins uses a jenkinsfile which is stored in the project repo, but I do not see the jenkinsfile in the calcite or kafka repos. How are builds configured? There is a sonarqube instance: https://wiki.apache.org/general/SonarInstance Maybe it can provide code coverage, but I think the Go plugin needs to be installed: https://github.com/uartois/sonar-golang Ideally, there should be build status and coverage status images that can be embedded in the README.md file. Regarding github pushes, I think it may be possible if the repo is hosted on Gitbox: https://gitbox.apache.org
          Hide
          julianhyde Julian Hyde added a comment -

          CI is important, but let's deal with it in a separate case. I think adding Apache headers is the only change necessary before this PR can go in.

          I don't feel strongly one way or the other about tags. There's no harm in recognizing pre-Apache releases, both in tags and on the history page. But people won't be able to download pre-Apache releases from Apache, or even via an Apache page. Otherwise it would seem that Apache endorsed such releases, which it can't, because they haven't passed a PMC vote.

          Show
          julianhyde Julian Hyde added a comment - CI is important, but let's deal with it in a separate case. I think adding Apache headers is the only change necessary before this PR can go in. I don't feel strongly one way or the other about tags. There's no harm in recognizing pre-Apache releases, both in tags and on the history page. But people won't be able to download pre-Apache releases from Apache, or even via an Apache page. Otherwise it would seem that Apache endorsed such releases, which it can't, because they haven't passed a PMC vote.
          Hide
          elserj Josh Elser added a comment -

          CI is important, but let's deal with it in a separate case. I think adding Apache headers is the only change necessary before this PR can go in.

          Agreed.

          Jenkins uses a jenkinsfile which is stored in the project repo, but I do not see the jenkinsfile in the calcite or kafka repos. How are builds configured?

          You can do it this route if you'd like, but I don't have much experience. For the other Jenkins jobs for Calcite and Avatica, I've just created the jobs by hand. It is just an administrative task to get you an account.

          I believe there's at least one person in HBase who has experience doing this against their master branch.

          Show
          elserj Josh Elser added a comment - CI is important, but let's deal with it in a separate case. I think adding Apache headers is the only change necessary before this PR can go in. Agreed. Jenkins uses a jenkinsfile which is stored in the project repo, but I do not see the jenkinsfile in the calcite or kafka repos. How are builds configured? You can do it this route if you'd like, but I don't have much experience. For the other Jenkins jobs for Calcite and Avatica, I've just created the jobs by hand. It is just an administrative task to get you an account. I believe there's at least one person in HBase who has experience doing this against their master branch.
          Hide
          francischuang Francis Chuang added a comment -

          I've added the Apache License header to the files.

          I will probably not add the pre-Apache tags, as the original boostport/avatica repo will still be around for those using the old import path (there will be a message in the README directing people to the new repo).

          Here's the current todo list:

          • Create release history page
          • Switch CI to Apache Jenkins
          • Use self-hosted coverage reporting tool (maybe sonarqube's golang plugin)
          • Update URL in the awesome-go list
          • Update driver description on Avatica website
          Show
          francischuang Francis Chuang added a comment - I've added the Apache License header to the files. I will probably not add the pre-Apache tags, as the original boostport/avatica repo will still be around for those using the old import path (there will be a message in the README directing people to the new repo). Here's the current todo list: Create release history page Switch CI to Apache Jenkins Use self-hosted coverage reporting tool (maybe sonarqube's golang plugin) Update URL in the awesome-go list Update driver description on Avatica website
          Hide
          julianhyde Julian Hyde added a comment -

          To be completist, can you add headers to README.md, .gitignore, and wercker.yml (see how we do it in Calcite for README.md, .gitignore, and .travis.yml).

          I don't know much about Go; did you intend to check in Gopkg.lock? If it's generated there's a good chance that it shouldn't be.

          README.md has a tantalizing mention of moby.yml; the "we hope to open source it" pertains to Boostport not Apache Calcite project; remove it? Also, explain what the "vendor" directory is and why you'd want to skip tests in it.

          README.md doesn't seem to include instructions on how to build the software from source. (Not necessary now, but necessary before release.)

          Show
          julianhyde Julian Hyde added a comment - To be completist, can you add headers to README.md, .gitignore, and wercker.yml (see how we do it in Calcite for README.md, .gitignore, and .travis.yml). I don't know much about Go; did you intend to check in Gopkg.lock? If it's generated there's a good chance that it shouldn't be. README.md has a tantalizing mention of moby.yml; the "we hope to open source it" pertains to Boostport not Apache Calcite project; remove it? Also, explain what the "vendor" directory is and why you'd want to skip tests in it. README.md doesn't seem to include instructions on how to build the software from source. (Not necessary now, but necessary before release.)
          Hide
          francischuang Francis Chuang added a comment - - edited

          Hey Julian Hyde

          Thanks for the comments. I added the header to wercker.yml and readme.md, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore

          The Gopkg.lock is a file generated by dep (https://github.com/golang/dep). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5.

          The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. See https://golang.org/cmd/go/#hdr-Vendor_Directories When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them.

          It does not make any sense to build Go libraries into a binary. The library should be add into a project using dep, which will checkout the source to the project's vendor directory. On compilation, Go will build a single static binary for the project.

          I've pushed updated the PR with changes to the readme and a license header to wercker.yml.

          Show
          francischuang Francis Chuang added a comment - - edited Hey Julian Hyde Thanks for the comments. I added the header to wercker.yml and readme.md, but I am not sure how to add the header to .gitignore. See the following in the calcite repo: https://github.com/apache/calcite/blob/master/.gitignore The Gopkg.lock is a file generated by dep ( https://github.com/golang/dep ). It is poised to become the official package manager for Go. This file must be committed as it contains the exact commit hashes of the dependencies installed. The Gopkg.toml file only contains the constraints, for example, use the minor versions of a dependency that is versioned at 1.2.1. Therefore, the lock file is required for reproducible builds. It is equivalent to the lock file used by NPM 5. The vendor directory is a standard go-specific folder that contains dependencies used by the go projects. See https://golang.org/cmd/go/#hdr-Vendor_Directories When running tests, libraries and projects do not run tests in the vendor directory. The vendored dependencies should have their own tests and the owner of the dependencies should be testing them. It does not make any sense to build Go libraries into a binary. The library should be add into a project using dep, which will checkout the source to the project's vendor directory. On compilation, Go will build a single static binary for the project. I've pushed updated the PR with changes to the readme and a license header to wercker.yml.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user asfgit closed the pull request at:

          https://github.com/apache/calcite-avatica-go/pull/1

          Show
          githubbot ASF GitHub Bot added a comment - Github user asfgit closed the pull request at: https://github.com/apache/calcite-avatica-go/pull/1
          Hide
          julianhyde Julian Hyde added a comment -

          Fixed in http://git-wip-us.apache.org/repos/asf/calcite-avatica-go/commit/cfc09cd. Thank you for donating this to Apache, Francis Chuang!

          I have logged CALCITE-1937 (web site) and CALCITE-1938 (first release) as follow-ups.

          Thanks for your explanation of Gopkg.lock above. It makes sense that we include it in the source distribution.

          Likewise thanks for the explanation of the vendor directory.

          Show
          julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/calcite-avatica-go/commit/cfc09cd . Thank you for donating this to Apache, Francis Chuang ! I have logged CALCITE-1937 (web site) and CALCITE-1938 (first release) as follow-ups. Thanks for your explanation of Gopkg.lock above. It makes sense that we include it in the source distribution. Likewise thanks for the explanation of the vendor directory.

            People

            • Assignee:
              julianhyde Julian Hyde
              Reporter:
              julianhyde Julian Hyde
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development