This is not so much of a programming question as it is about the convention. What does Reply 'Done' conventionally mean as an alternative to just Reply to a comment on a code review in Gerrit?
Does it mean I agree with you and will do it or have done it locally or does it mean I have amended the change per your suggestion? Because if I amend the change and push it into the same Gerrit review, the latest file revision on which the comments are made will overwrite the previous and all the comments from before will be gone (at least that's been my experience).
The "Done" comment means that the comment has been addressed, typically by making the changes that the reviewer suggested. One normally publishes such comments after a new patch set has been pushed so that reviewers can have a new look and hopefully approve the change. Publishing the comments before the new patch set is actually available means that you'll be interrupting reviewers before there's anything new to look at.
Comments are never "gone". I don't know what you mean by that. It's perfectly okay to publish comments made on previous patch sets. Patch sets don't replace each other.
Related
In Bitbucket, on any Pull Request, reviews are disabled after the PR is merged.
I'd like to continue to allow reviews after a PR is merged. Is this possible?
NOTE: I am not asking about requiring review approval pre-merge, though I may or may not have those requirements as well. I want post-merge reviews.
In Github, by way of comparison, it is possible to "review" a PR even after it is merged.
I tried clicking the greyed-out "review" button after merging, which obviously did nothing. If the page is reloaded the "review" button is entirely gone.
I have been in contact with a wonderful Product Manager at Atlassian, and he let me know that this used to be an accidental "feature" of BitBucket, which they considered a bug, and fixed as of several months ago. This is why people have a memory of post-merge reviews, which seem to no longer be possible (because, they indeed are no longer possible).
He explained that once they "fixed" the bug they heard from users who had built workflows around it, and wanted the "bug/feature" back.
There is a public issue tracker for this if you are interested in weighing in on it!
https://jira.atlassian.com/browse/BCLOUD-22396
Atlassian has not yet decided if/when/how they will bring the "bug/feature" back.
I have used a few code review programs. I am now using pull requests in Bitbucket. I am expecting a certain process:
Create review (ie pull request)
Comments are added by reviewers. ( am used to a graded system where someone can mark the change as a bug which needs to be fixed before being merged)
The review is sent back to the originator who fixes any problems that are marked
(!!)The originator pushes their changes to their branch and then the code review is done again by all reviewers who then approve or reject the new changes.
With all things being good, the review is approved and then merged.
What I am wondering about are steps 3 and 4. There seems no grading to the comments and there seems to be no way for the originator to see quickly the comments (in some condensed format). Also, how do new changes update a pull request? Is this just missing from the Bitbucket system or is there a way to achieve this?
"there seems to be no way for the originator to see quickly the comments (in some condensed format)". Open a pull request, and look over on the right hand side. I see 3 tabs: Details / Files / Activity. Under "Activity", I can filter to "All Comments".
"how do new changes update a pull request?" When creating a pull request, you are requesting approval from your colleagues to pull code from some source branch to some target branch. So, when the source branch is updated with changes, the pull request should automatically reflect that. In other words, you shouldn't have to take any extra action.
"There seems no grading to the comments" A reviewer can check a box that says "merge not allowed until the 'issue fixed' box is checked." The repo admin has some latitude to set how strict the PR / merge policies will be, including whether approval is needed from anyone or from specific individuals.
So I understand that once I open a pull request, I automatically get a code review for the code that's about to be merged, that's great! But is there a a way to create a Code review without creating a Pull Request? For example, let's say I am working on a feature and I would like to do a code review with peers, but I don't want to do a Pull Request as the feature is still Work In Progress.
I understand that I can use the "compare" feature in BitBucket to see the code diff, but I needed the "Codereview" kind of feature explicitly so that I can:
Share the code review link with my peers so that they can see it
They can comment and open "tasks" on the code
and all of it while not creating a Pull Request. Is that possible?
Question is already asked here.
The usual process is to start code review based on a pull-request (this is how I understand the usage in BitBucket).
It is acceptable to create the pull-request and mark it as in progress and you can always add more commits on the PR later.
This is explained in the official doc:
But, the pull request is more than just a notification—it’s a dedicated forum for discussing the proposed feature. If there are any problems with the changes, teammates can post feedback in the pull request and even tweak the feature by pushing follow-up commits. All of this activity is tracked directly inside of the pull request.
Your peers must be aware that you don't need immediate approval but just comments until you finish the feature (PR ready to be merged)
I would like to check in code after a code review is approved. I came across this stack about creating code reviews and checking in, but my question is a little different.
My issue is that I want to create a code review; however, I do not want to check in the code until it is approved. That limits me from being able to start another code review with removing related work items. What I would like to do is create code reviews and check in from the code review tab in the Team Explorer
Is that possible? It is the same principle as creating a code review after the check in, but with Code reviews and checking in. I do not want to go to pending changes and check in there because I may have removed the related items. But I do want a check in to be tied to my code review.
Unfortunately, there is no "proper" way to do what you are trying to do. You could have your working directory on a shared drive and just notify your reviewer when you are ready for them to start their review process, but that side-steps the accountability by not having each development/review iteration officially logged within TFS. This means you should check in your work and let the reviewer do their job, then continue on in that fashion to make any changes requested by the reviewer, check in, and get another code-review.
For completeness I will mention my suggestion from my comments here as well.
My suggestion would be to create a self-contained, short-lived development branch where you will do your development and have your code reviewed. Then once the development and reviewing has been completed to satisfaction, that branch can be merged back up and destroyed. This provides a much cleaner and safer approach. 1) It reduces the clutter in the history within TFS. 2) It prevents multiple unnecessary automated builds/tests/etc... from being triggered.
In your comment you suggest that this changes the "structure of your branching methods". I don't see how doing this changes anything in any way that matters. Your merge would be just like your final development check-in except that by this time all reviews have been completed and you are performing a single, clean check-in. It will still contain all of your check-in and review information, however instead of a cluttered chain of check-ins, you will have a single collapsed node which contains every single thing that was done for that particular task.
I would check with your manager, your code reviewer and/or anyone you have that is in charge of TFS and creating/maintaining your TFS policy. This approach really doesn't change anything in regard to how the rest of your process works. You would have simply abstracted your development cycle to a self-contained environment. The second you perform your merge you are right back into your normal process as you have it now.
Okay, so for documentation purposes. I did not fully understand the shelving that TFS allow me to do. After reading Shelve and Unshelve Pending Changes, it makes more sense to me. I can shelve what I am working on, unshelve the code that I have done a code review for, then check in that code. That way I can create a code review and continue working until that code review is approved. Once approved, I can go unshelve the changes and check it in.
we are going to use gerrit for the source code reviewing and code repository. as we know, for each change, anyone can review it, and give the comments in specific line of source code.
My question is, is there any state of the review comments such like (new/open/closed)? or how to check previous review findings have been fixed or still open there?
Is there any life cycle of review comment? and how to measure it? I used gerrit REST API to read it, but no such information there, or I miss something?
No there isn't. It would be useful as a new patchset will hide previous comments and it is not clear which comments have been fixed and closed.
This is not currently possible. Comments don't have a state or any kind of tracking between patch sets.
Basically you have to rely on the change owner adding a "Done" comment at the same line (on the same patch set).
Also note that if there are multiple comments on the same line, it's not possible to reply to a specific one.