On 25/01/16 05:44 PM, Eric Rescorla wrote:
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
It's not terribly obvious, but instead of clicking on a line number you
can click and drag on the numbers to set the exact amount of context you
want.
-Andrew
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
