Return expect to verify neo-cli #3318
Conversation
So we can run the test locally? |
Yes, organization and for |
.neo is not appropriate, a hidden folder. I script, for now, a Script folder inside Neo.CLI itself. |
There was a problem hiding this comment.
We don't scripts included the csproj files. Just create a folder /scripts/Neo.CLI and put there. If doesn't make sense to put in with source files.
There was a problem hiding this comment.
You can fix it in another pr. If @vncoelho 's purpose is bring this back to the project. Please let him just bring it back.
There was a problem hiding this comment.
I'm agree with do it organized, why we need to create one pr for one thing and other for move it? review is for this, the solution is not create a new pr.
There was a problem hiding this comment.
I'm agree with do it organized, why we need to create one pr for one thing and other for move it? review is for this, the solution is not create a new pr.
The problem is this pr from @vncoelho is to bring expert back, moving it somewhere is a request from @cschuchardt88 , which is not what @vncoelho wanted to do..... Why would you require/enforce @vncoelho to do a thing that is out of the scope of his pr? I am not against of making it organized, but what if @vncoelho just not willing to apply his suggestion? what we do with this pr then? close it and open another one?
So my point is very simple, one pr for only one task, if you agree that we should bring expert back, and @vncoelho 's pr has fullfilled this purpose, we should be fine with this pr. You can have suggestions, but that should not be a reason of enforcing unless there is a real problem in the pr.
From our past working experience, i believe having small prs (real pr that can fix problem without introducing new problem), is the only way we can make it forward.
BUT, its just my personal suggestion.
There was a problem hiding this comment.
His suggestion is good anyway, I will move to the main folder.
There was a problem hiding this comment.
Something I would like to highlighted is that @cschuchardt88 is using the Requested Changes too much.
I think that this is more useful when you are really blocking something for a good reason.
These uses like this are not necessary and just reduce the criteria we will often look to these requests.
There was a problem hiding this comment.
I'm agree with do it organized, why we need to create one pr for one thing and other for move it? review is for this, the solution is not create a new pr.
The problem is this pr from @vncoelho is to bring expert back, moving it somewhere is a request from @cschuchardt88 , which is not what @vncoelho wanted to do..... Why would you require/enforce @vncoelho to do a thing that is out of the scope of his pr? I am not against of making it organized, but what if @vncoelho just not willing to apply his suggestion? what we do with this pr then? close it and open another one?
So my point is very simple, one pr for only one task, if you agree that we should bring expert back, and @vncoelho 's pr has fullfilled this purpose, we should be fine with this pr. You can have suggestions, but that should not be a reason of enforcing unless there is a real problem in the pr.
From our past working experience, i believe having small prs (real pr that can fix problem without introducing new problem), is the only way we can make it forward.
BUT, its just my personal suggestion.
I completely agree with you. This should be a common sense for most of the PRs.
Stop trying to block PRs for nonsense things that are not the goal of the PRs themselves.
There was a problem hiding this comment.
I'm agree with do it organized, why we need to create one pr for one thing and other for move it? review is for this, the solution is not create a new pr.
The problem is this pr from @vncoelho is to bring expert back, moving it somewhere is a request from @cschuchardt88 , which is not what @vncoelho wanted to do..... Why would you require/enforce @vncoelho to do a thing that is out of the scope of his pr? I am not against of making it organized, but what if @vncoelho just not willing to apply his suggestion? what we do with this pr then? close it and open another one?
So my point is very simple, one pr for only one task, if you agree that we should bring expert back, and @vncoelho 's pr has fullfilled this purpose, we should be fine with this pr. You can have suggestions, but that should not be a reason of enforcing unless there is a real problem in the pr.
From our past working experience, i believe having small prs (real pr that can fix problem without introducing new problem), is the only way we can make it forward.
BUT, its just my personal suggestion.
Something I would like to highlighted is that @cschuchardt88 is using the Requested Changes too much. I think that this is more useful when you are really blocking something for a good reason. These uses like this are not necessary and just reduce the criteria we will often look to these requests.
Than you should be creating a Issue and assigning someone to that task. I can't keep being the repo cleaner upper. Put some thought into it, that's all. Just remember no one can do it the right way but yourself. No copy/paste and hope.
* master: Fixed pathing and Property (neo-project#3306) [Neo CLI New Feature] Allow custom plugins (neo-project#3295) Return expect to verify neo-cli (neo-project#3318) [Neo CLI Optimization] fix exception message (neo-project#3314) fix plugin download url (neo-project#3329)
Restoring the structure from https://github.com/neo-project/neo-node/tree/master/.github/workflows
part #3256