You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openwhisk.apache.org by GitBox <gi...@apache.org> on 2021/03/23 17:27:07 UTC
[GitHub] [openwhisk-wskdeploy] advancedwebdeveloper opened a new pull request #1134: Diversifying the reflection API usage, for DeploymentReader test
advancedwebdeveloper opened a new pull request #1134:
URL: https://github.com/apache/openwhisk-wskdeploy/pull/1134
Consult the following discussions, for farther details:
https://groups.google.com/g/golang-nuts/c/S2gBW3BV4QU/m/I4gWtrPxBwAJ
https://github.com/apache/openwhisk-wskdeploy/issues/1130
Compared to a summary, known threw a patch https://gist.github.com/advancedwebdeveloper/9ee1d333d0101b06823735cf871055b1 - the code above was not formatted automatically, via https://pkg.go.dev/golang.org/x/tools/cmd/goimports
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-wskdeploy] mrutkows edited a comment on pull request #1134: Diversifying the reflection API usage, for DeploymentReader test
Posted by GitBox <gi...@apache.org>.
mrutkows edited a comment on pull request #1134:
URL: https://github.com/apache/openwhisk-wskdeploy/pull/1134#issuecomment-805817993
Although I have read the attached discussion thread (which itself lacked context) I am not inclined to begin using a 3rd party alternative unless there is a compelling reason to especially if there are no apparent functional issues with the code as it exists today. In addition, it seems that the actual owner of the "reflect" lib in golang itself is trying to understand some minor optimization and resultant performance issues and fix them in the base golang; if so, then I am inclined to wait for those changes to be picked up in an actual golang release/update.
Also, we should not be using Travis PR builds simply to use as an alternative local test bed; the ASF pays for Travis.com usage and we should not be abusing the privilege. Unit tests for your purposes (i.e., testing a new lib.) are sufficient until you are ready to submit a final PR with the complete solution along with additional unit tests. If indeed, you are fixing a problem, we should have an issue for it that provides continuity of discussion on the topic (here in this project) and it should be linked to the eventual PR. I still do not have a compelling answer as to what problem you are trying to solve other than inferring that you believe that our client tools must support some divergent ARM64 architecture (guessing M1) more quickly than the base golang compiler does. IMO, we would need the compelling argument to go down this path for not only this tool, but also for all the client tooling within the entire project that uses golang.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-wskdeploy] mrutkows edited a comment on pull request #1134: Diversifying the reflection API usage, for DeploymentReader test
Posted by GitBox <gi...@apache.org>.
mrutkows edited a comment on pull request #1134:
URL: https://github.com/apache/openwhisk-wskdeploy/pull/1134#issuecomment-805817993
Although I have read the attached discussion thread (which itself lacked context) I am not inclined to begin using a 3rd party alternative unless there is a compelling reason to especially if there are no apparent functional issues with the code as it exists today. In addition, it seems that the actual owner of the "reflect" lib in golang itself is trying to understand some minor performance issues and fix them in the base golang; if so, then I am inclined to wait for those changes to be picked up in an actual golang release/update.
Also, we should not be using Travis PR builds simply to use as an alternative local test bed; the ASF pays for Travis.com usage and we should not be abusing the privilege. Unit tests for your purposes (i.e., testing a new lib.) are sufficient until you are ready to submit a final PR with the complete solution along with additional unit tests. If indeed, you are fixing a problem, we should have an issue for it that provides continuity of discussion on the topic (here in this project) and it should be linked to the eventual PR. I still do not have a compelling answer as to what problem you are trying to solve other than inferring that you believe that our client tools must support some new, divergent architecture more quickly than the base golang compiler does. IMO, we would need the compelling argument to go down this path for not only this tool, but also for all the client tooling within the entire project that uses golang.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-wskdeploy] mrutkows edited a comment on pull request #1134: Diversifying the reflection API usage, for DeploymentReader test
Posted by GitBox <gi...@apache.org>.
mrutkows edited a comment on pull request #1134:
URL: https://github.com/apache/openwhisk-wskdeploy/pull/1134#issuecomment-805817993
Although I have read the attached discussion thread (which itself lacked context) I am not inclined to begin using a 3rd party alternative unless there is a compelling reason to especially if there are no apparent functional issues with the code as it exists today. In addition, it seems that the actual owner of the "reflect" lib in golang itself is trying to understand some minor optimization and resultant performance issues and fix them in the base golang; if so, then I am inclined to wait for those changes to be picked up in an actual golang release/update.
Also, we should not be using Travis PR builds simply to use as an alternative local test bed; the ASF pays for Travis.com usage and we should not be abusing the privilege. Unit tests for your purposes (i.e., testing a new lib.) are sufficient until you are ready to submit a final PR with the complete solution along with additional unit tests. If indeed, you are fixing a problem, we should have an issue for it that provides continuity of discussion on the topic (here in this project) and it should be linked to the eventual PR. I still do not have a compelling answer as to what problem you are trying to solve other than inferring that you believe that our client tools must support some new, divergent architecture more quickly than the base golang compiler does. IMO, we would need the compelling argument to go down this path for not only this tool, but also for all the client tooling within the entire project that uses golang.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-wskdeploy] mrutkows commented on pull request #1134: Diversifying the reflection API usage, for DeploymentReader test
Posted by GitBox <gi...@apache.org>.
mrutkows commented on pull request #1134:
URL: https://github.com/apache/openwhisk-wskdeploy/pull/1134#issuecomment-805817993
Although I have read the attached discussion thread (which itself lacked context) I am not inclined to begin using a 3rd party alternative unless there is a compelling reason to especially if there are no apparent functional issues with the code as it exists today. In addition, it seems that the actual owner of the "reflect" lib that is golang itself is trying to understand some minor performance issues and fix them in the base golang; if so, then I am inclined to wait for those changes to be picked up in an actual golang release/update.
Also, we should not be using Travis PR builds simply to use as an alternative local test bed; the ASF pays for Travis.com usage and we should not be abusing the privilege. Unit tests for your purposes (i.e., testing a new lib.) are sufficient until you are ready to submit a final PR with the complete solution along with additional unit tests. If indeed, you are fixing a problem, we should have an issue for it that provides continuity of discussion on the topic (here in this project) and it should be linked to the eventual PR. I still do not have a compelling answer as to what problem you are trying to solve other than inferring that you believe that our client tools must support some new, divergent architecture more quickly than the base golang compiler does. IMO, we would need the compelling argument to go down this path for not only this tool, but also for all the client tooling within the entire project that uses golang.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org