On Mon, Jan 25, 2016 at 1:58 PM, Mike Hommey <m...@glandium.org> wrote:
> 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. > Indeed. It would be great if it would just include 5-8 lines of context by default. -Ekr > > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
