On Friday 06 June 2014 10:03:51 Dave Gomboc wrote:
[Paul A Bristow]:
I unhappy with a review rigid policy that nothing can be changed during a review. It isn't always helpful.
We never accept anything without requiring some changes?
Can we instead now use git's easy branches to specify a fixed 'master' branch, but allow the author to update a 'develop' branch as the review develops? [Edward Diener]: I believe that changes can be made to a reviewed library during a review as long as the 'master' branch does not change. After all we want all reviewers to be looking at the same 'master' branch as the code to be reviewed. But if the developer wants to make changes to other branches during the review I think this should be allowed.
May I suggest that either the library author or the review manager ought to, near the commencement of the review, identify a specific version to be reviewed? This is quite distinct from identifying a branch name for a conventional branch such as master that is expected to change frequently even over a two-week period. A specific checkout is typically identified by a SHA: a branch name such as 'master' is primarily just an alias to the SHA to which it currently resolves.
I think a tag would be a better alternative to a SHA. It's more readable and GitHub creates a downloadable archive for it so git is not required to review the library.