On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote: > Heh. Your list of UI complaints is very similar to mine. Some comments: > > > On 01/25/2016 04:26 AM, Honza Bambas wrote: > >Writing both as a patch author and a reviewer as well. > > > >- as a patch author I want a full control on when the patch actually lands > >(dependencies, any other timing reasons, that only the author knows the > >best), "Don't land yet" comment somewhere will easily be overlooked > >- as a reviewer I don't want to bare the decision to land or not to land, > >at all > >- I want to preserve the mechanism "r+ with comments", which means to let > >the patch be landed by the author after updated (means reviewer doesn't > >need to look over it again) > >- as an author I want to write comments about the patch (about the > >structure, what it does, why) to make the review simpler for the reviewer > >; commit message description may not be the best place, right? > > Yes, is there a place for this? I feel this is a really important bit of > functionality that would fit naturally into the mozreview world, but I don't > see how to do it. Situation: I put up a set of commits for review, and I > want to give per-commit notes to the reviewer that they'll see before > reviewing. Previously, I would put them in as comments on the bug and either > pray that the reviewer happened to see them, or ping the reviewer on IRC and > tell them to read them. In MozReview, I don't see a place to put such things > at all?
It's also painful to use MozReview's comment system. The comments in the reviews pane don't show much diff context, and while I just realized it's possible to make it show more by hovering the diff part for a little while, it's not really great, as it doesn't actually show a diff view like the diff pane does, and switching to the diff pane a) is slow for large diffs and b) has an entirely different comment UX that doesn't seem really great either. Also, iirc, when you reply diff comments in MozReview, the resulting comments sent to bugzilla lack context (but I could be misremembering). > >- will it be possible to still be using hg patch queues? > > A valid question, though I'd not that the mq-less workflow is actually > pretty good these days. mq is still easier/nicer for some things, but doing > without mq is nicer in other ways, and the future leads away from mq. > > On the other hand, there still isn't a great way to figure out the mq-less > workflow. I remember a pretty good writeup from someone, and I intend to > write up my own. But there isn't anything that's easily discoverable. Whether or not mq is deprecated, it still uses changesets that can be pushed. And with a non publishing remote repository, it should still be able to qpop without having to fool around with the draft state. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
