On Mon, Apr 4, 2016 at 9:23 PM, Mark Côté <mc...@mozilla.com> wrote:
> On 2016-04-04 10:07 AM, Eric Rescorla wrote: > > On Sun, Apr 3, 2016 at 10:09 PM, L. David Baron <dba...@dbaron.org> > wrote: > > > >> On Saturday 2016-04-02 18:51 -0300, Eric Rescorla wrote: > >>> 1. I write a bunch of code, committing along the way, so I have a lot > of > >>> commits named "Checkpoint" and "Fix bug" and the like. > >>> 2. When it works, I push the code up to the review system for review. > >>> 3. In response to review comments, I add a bunch more changes as new > >>> commits and push them up the review system for review. > >>> 4. Repeat 2 and 3 until I get r+ > >>> 5. Squash everything into one commit and land it. > >>> > >>> Every time I do #3, it creates a new review request, but as you can > see, > >>> this doesn't have any meaningful connection to my local commits, which > >> is a > >>> good thing because while I want to keep my local history, I don't want > it > >>> to show up either in review or in the tree. This is also the way I want > >> to > >>> see patches because I want to review the whole thing at once. > >> > >> This is why I use mq. With mq, I maintain the sequence of > >> changesets that are the logical units to be committed (and submitted > >> for review), and I have the history of that sequence (in a > >> version-controlled patch repository). > >> > >> It's useful for reviewability and for bisection for the logical > >> units that I commit to be small and (for review) understandable. > >> And it's useful for me to have a history of the work I've done, for > >> backups, for the ability to revert, and for the ability to remember > >> what I did and why. > >> > >> I still think this is a good model for doing development, despite > >> the attempts of Mercurial developers to deprecate it. I recognize > >> that it's not the right tool for everybody, though. > >> > > > > Fair enough, but I use git :) > > > > I generally don't have trouble keeping the logical changesets straight > > with git and git rebase, which is good about merging and splitting. > > > > I'd like to state for the record that I'm not trying to change anyone's > > workflow nor am I trying to create a lot of work for reviewers. I'm > simply > > asking for the tools to accommodate the workflow that I and a bunch of > > other people use, said accommodation being, I believe, relatively > > modest. > > Indeed, we talked about supporting this before, and it is planned; see > https://bugzilla.mozilla.org/show_bug.cgi?id=1217861. However right now > we are focussing on UI issues to improve reviewer experience. Early > MozReview development was focussed mainly on author experience > (admittedly largely for Mercurial-using developers), which got a lot of > people using MozReview, but that in turn surfaced a lot of confusion and > suboptimal workflows for reviewers. I'd like to keep focussed on that > for the next quarter or so, since reviewer time is generally perceived > to be more valuable than author time. > > To answer the original question, though, at this time we have no plans > to completely do away with the squashed-commit view. However, in the > interests of ensuring that the commits that will land are the ones > reviewed, we are thinking of making the squashed diff read-only--and > also more obvious and easy to find, probably by not making it a proper > review request, just a diff linked off the commit table (the layout of > which we also have plans to improve). I agree that seeing the entirety > of a series of commits in a single diff can be useful. What does read-only mean? If it's that you can't comment on it, then that doesn't work. -Ekr > > Mark > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
