Gregory Szorc wrote:
Support for specifying the base revision to review has landed. Just
pull and update version-control-tools and you can use `hg push -r
base -r tip` or `hg push -r base::tip`.
\o/ Thank you!
- Blair
___
dev-platform mailing list
Hi, I've been trying MozReview and I'm having trouble with updating a
review with changes for my reviewers to verify. The documentation says,
Oh, it just works, but in my case it doesn't.
I'm using the evolve extension, so my repo have obsolescence markers,
but I don't see them being sync'd
On 11/12/14 10:39 PM, Dan Glastonbury wrote:
Hi, I've been trying MozReview and I'm having trouble with updating a
review with changes for my reviewers to verify. The documentation says,
Oh, it just works, but in my case it doesn't.
I'm using the evolve extension, so my repo have obsolescence
On 11/10/14 9:14 AM, Gregory Szorc wrote:
On 11/9/14 8:29 PM, Boris Zbarsky wrote:
On 11/9/14, 11:10 PM, Gregory Szorc wrote:
We currently only attempt to map each review/commit series to a single
bug.
This is definitely a problem; it serializes workflow such that you have
to get review on
Is there any chance we could log in with Persona?
Cheers,
David
On 06/11/14 05:50, Mark Côté wrote:
A couple months ago I gave a sneak peak into our new repository-based
code-review tool based on Review Board. I'm excited to announce that
this tool, now named (descriptively but
It looks like all reviews (and patches) are currently public. Is there
some way to have them not be so, for security/confidential bugs/reviews?
~ Gijs
On 06/11/2014 04:50, Mark Côté wrote:
A couple months ago I gave a sneak peak into our new repository-based
code-review tool based on Review
Unfortunately that's very difficult given the various communication
pathways between hg review repo, the Review Board API, and the BMO API,
especially considering BMO's support of Persona is a bit sketchy. We'll
look into it, but it's not a high priority at the moment.
Mark
On 2014-11-10 5:51
That is an excellent point which I forgot to call out: please do NOT try
to use MozReview for confidential/security/nonpublic patches. MozReview
will actually prevent you from publishing a review request linked to a
nonpublic bug. Review Board does not have anything close to the
fine-grained
This is awesome, everything seems to be working great so far!
While adapting to mozreview, I also took the opportunity to use hg
bookmarks instead of mq and to switch to a unified repo (m-c, m-i, m-a
etc, all in the same local clone). If anyone else is thinking about
making a similar switch
On 11/9/14 8:29 PM, Boris Zbarsky wrote:
On 11/9/14, 11:10 PM, Gregory Szorc wrote:
We currently only attempt to map each review/commit series to a single
bug.
This is definitely a problem; it serializes workflow such that you have
to get review on bug 1 and land it before you can even
On 11/10/14, 12:14 PM, Gregory Szorc wrote:
I think if we land support for specifying the base revision to review
(currently it takes all non-public changesets up to the revision you
specify or . if none), that will be a sufficient stop-gap until proper
multi-bug support is implemented.
Yes,
It's quite common for me to be working on a bug that depends on another
bug that hasn't landed yet. I'm struggling to figure out how to make
this work with MozReview, since everything is lumped into one review
group and associated with one bug.
ie, I have:
* Bug 1 - patch A (this is either
We currently only attempt to map each review/commit series to a single bug.
We will support multiple bugs eventually. Single bugs were easy to implement :)
There is also an open bug to support specifying the base revision to review.
Right now everything on the stack gets reviewed. That should
On 11/9/14, 11:10 PM, Gregory Szorc wrote:
We currently only attempt to map each review/commit series to a single bug.
This is definitely a problem; it serializes workflow such that you have
to get review on bug 1 and land it before you can even request review on
bug 2 that depends on bug 1,
Cool. I'm eager to try this out. Sadly
https://hg.mozilla.org/hgcustom/version-control-tools is giving me a
503 error at this time.
On Wed, Nov 5, 2014 at 11:50 PM, Mark Côté mc...@mozilla.com wrote:
A couple months ago I gave a sneak peak into our new repository-based
code-review tool based on
All of hg.m.o is currently 503
https://bugzilla.mozilla.org/show_bug.cgi?id=1094922
~ Gijs
On 06/11/2014 16:58, Benoit Girard wrote:
Cool. I'm eager to try this out. Sadly
https://hg.mozilla.org/hgcustom/version-control-tools is giving me a
503 error at this time.
On Wed, Nov 5, 2014 at
16 matches
Mail list logo
