Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Fix variable names in WireProtocol_Receiver #60

Merged
merged 1 commit into from
Jan 17, 2017
Merged

Fix variable names in WireProtocol_Receiver #60

merged 1 commit into from
Jan 17, 2017

Conversation

josesimoes
Copy link
Member

  • Addresses #59

Signed-off-by: José Simões [email protected]

@josesimoes
Fix variable names in WireProtocol_Receiver
67293c0 
- Addresses #59

Signed-off-by: José Simões <[email protected]>
@josesimoes josesimoes requested a review from cw2 January 17, 2017 10:13
@josesimoes josesimoes added the Area: Interpreter Everything related with the interpreter, execution engine and such label Jan 17, 2017
cw2
cw2 approved these changes Jan 17, 2017
View reviewed changes
Copy link
Contributor

@cw2 cw2 left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Thanks.

@cw2 cw2 merged commit 41fe016 into nanoframework:dev-cmake-build Jan 17, 2017
@josesimoes
Copy link
Member Author

👍
When a PR is merged, if it fixes one or more issues the merger should be responsible for closing those issues, otherwise they'll may end remaining open for nothing.

@josesimoes josesimoes deleted the Fix-variable-names-in-WireProtocol_Receiver.c branch January 17, 2017 14:33
@cw2
Copy link
Contributor

cw2 commented Jan 17, 2017

Well, that depends on the result of the verification of the bug. Unfortunately, github has rather limited workflow for bugs, the usual ... fixed -> verified -> closed is not really possible [yet] here.

Merger can set the issue as fixed, but the original reporter (or a dedicated tester) can only close the issue after it has been verified (that it was really fixed).

@cw2
Copy link
Contributor

cw2 commented Jan 17, 2017

(I think this is how it works at BitBucket - you can include fix/resolve/close etc. words in the comments, but those set the appropriate state, not always closing the bug as it is done here).

@josesimoes
Copy link
Member Author

I'm afraid I fail to follow that logic...
If there is PR that is supposed to fix an issue, assuming it has been properly reviewed and tested (to fix that issue, otherwise it would be for something else) how come that after all that the issue may not be fixed, therefore can be closed?! 😲 ❓ ❓

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@cw2 cw2 cw2 approved these changes

Assignees
No one assigned
Labels
Area: Interpreter Everything related with the interpreter, execution engine and such
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@josesimoes @cw2