What happened to a change, if it has no revisions?
You can find an instance of this phenomenon with change 8906 in the LibreOffice Gerrit or change 9860 in the OpenStack Gerrit. There is no correlation to their status or user access control.
Probably the 8906 is a Draft change. Only the owner and the reviewers can see a Draft change.
Related
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.
I have a Jenkins setup to be triggered by Gerrit once a patch is updated. Verified label has a negative rating from Jenkins. This rating is irrelevant in my case and so I just want to ignore it for this one time. Is that possible ?
It is not possible to ignore the vote but it is possible to delete it if you have the correct access rights.
After this you can vote +1 Verified and you should be able to submit.
Of course, this all depends on the server configuration and access rights.
In our case we have given some developers the rights to delete and vote on the Verified label of other developers, this is a way to get around Jenkins issues.
We're having some serious issues with the mfbclient.exe tool that is part of the feedback platform of VSTS. Basically, our stakeholder's uploads are not being sent.
This is extremely frustrating as you can imagine, as the ability to take screenshots etc is a major benefit of using the tool.
Members of the development team who have VS2017 installed on their machines as well as the feedback tool, can access the feedback request via the email that is automatically sent out when you click on "Request Feedback". Everything works perfectly.
If we send the request to a stakeholder, they can click on the link and it opens up the tool correctly, they can step through the items and make notes etc., and when they submit, their responses come through into VSTS. However, none of their attachments come through. They all say '(Uploading) filename.png' in VSTS.
Upon looking at one of the stakeholder's machines, I can see the mfbclient.exe tray icon says '0MB of 10MB transferred'. Restarting the machine doesn't change this - the attachments don't get uploaded.
Upon further investigation, under %localappdata%\microsoft\team foundation\x.0\testmanagement\ i can see an XML file which contains the list of all the screenshots / attachments etc that are to be loaded. The screenshot files themselves also exist (so, the files aren't missing/deleted). For some reason, the files just aren't uploading.
If I remove the XML file, it clears the attachment 'queue', but as soon as more feedback is entered and a screenshot added, the same issue occurs.
I noticed there was an mfbclient.exe.config file, which I edited on one of the stakeholder's machines and changed the trace level to '4' (verbose), which I thought would shed some light on the issue. However, I can't see anywhere that the logs might be. Does anyone know?
I have tested this with the stakeholder being part of the exact same security group as myself and the team (as I thought perhaps it was a permissions error), but this doesn't change the behaviour.
The only real differences I can think of between myself and team, and the people who are having the issues (and there are quite a few users who have the same issue so it's not just 1 person's problem), is that these people are stakeholders rather than subscribers (shouldn't make a difference), and they don't have Visual Studio installed on their machines (also, shouldn't make a difference).
Can anyone please shed any light on this issue? Has anyone else had the problem? Can someone from MSFT help?
Just as Sebastian mentioned, the solution is changing the Access Level from Stakeholder to Basic.
Basic provides access to most features, except for Test and other premium features. Stakeholder access to those users who need to
enter bugs, view backlogs, boards, charts, and dashboards, but who
don't have a TFS CAL. See About access levels for details.
Basic provides most features, Stakeholders can use the Feedback Client since TFS 2013 Update#5 based on this user voice. Can't attach pictures seems a permission limitation for Stakeholders.
Whatever seems it's by design or a feature missed or an issue on current version of TFS and VSTS based on the Stakeholders license limitation. However the requirement make sense and I have submitted a new user voice here to suggest the feature, you can go and vote it up to achieve that in future.
UPDATE:
I agree with your point of view, it's more inclined to be a bug. And you have submittetd a feedback here: Feeback Client - Upload fails for Stakeholder
Whether user voice or bug, development team will take care of them. So, let's wait for the response. And for now, you can change to the Basic Level to upload the pictures.
I have the same problem with our VSTS.
The problem really is because of the Stakeholder-License.
If I submit a feeback with a stakeholder account the upload stays at 0%. When I change the user then to Basic in VSTS, the upload starts automatically and completes.
EDIT: this issue has been fixed, as per this forum post: Feedback Client - Upload fails for Stakeholder
Since we migrated from VSS to TFS the version history shows a single user and day for every commit. The original users and dates for each commit are displayed in the check-in comment.
Is this the best we can do? Isn't there a way to migrate putting the original User into the "User" column and the original date into the "Date" column?
This is the expected behavior. There is no supported way to migrate history from a non-TFS repository and maintain a true history (outside of comments). TFS team does this on purpose so as to maintain the integrity of the audit trail (instead of having TFS "lie" about when that change was checked into TFS).
In practice it is usually sufficient as you still have the changes in the proper order, and if you're going back to inspect history the information you want (date/time, user) is still captured, just not in the ideal location.
I recently moved to the new Bitbucket interface and what I remarked is that I need to approve commits after pushing them.
It's a good feature, but it's inconvenient for my work-flow. Is there an option to disable it and have the commits automatically approved?
Edit: I uploaded an image of the Approve button.
"Approve" is not necessary, is an extra feature to know who reviewed the commit. From Bibucket's blog post:
Giving the green light
Bitbucket has a light-weight approval process that allows participants
to Approve a commit or pull request – this signifies that a user has
reviewed a change and that it LGTM.
Later, when browsing the list of commits or pull requests, Bitbucket
displays the total number approvals for a particular change as a gray
circle.
A gray badge shows how many reviewers have approved a particular
change – now, for those commits or pull requests that you personally
have approved, the badge is now green giving you a quick summary of
changes that are yet to be reviewed by you.