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.
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.
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.
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.
I've been looking for a way to have a user acknowledge a
ticket after it has been assigned to them. I don't know if
this is a built in feature or if there is a plugin that
will create a state/button for a user to accept a ticket
after it has been put in there queue. I would expect to
see something like this from the ticket window around
workflow or start progress but no amounts of digging
through configuration settings has turned anything
relevant up.
Does anyone know about this added functionality in JIRA?
Much thanks.
I did this by a custom workflow step. After an issue arrived to an assignee (with status New) he/she should move it to another step (with status Open). Until he/she does it, the issue is considered as not noticed/reached the assignee. Also I have had a report showing issues with New status for more than a predefined period of time.
I'm not aware of a ready-made plugin which performs similar task (perhaps, I should dig into my posts on Atlassian answers to discover some clues for other solutions).
As #Stan says above, a custom workflow is the way to implement this. The workflow functionality in JIRA is very flexible and as a result has a bit of a learning curve, but Atlassian's documentation is pretty good. Post back here if you need help.