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
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
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
-r ` or `hg push -r ::`.
\o/ Thank you!
- Blair
___
dev-platform mailing list
dev-platform@l
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 bu
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, ag
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 request
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 an
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 secu
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 A
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 Bo
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 unimaginat
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,
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 ho
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 wai
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 11:50
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é wrote:
> A couple months ago I gave a sneak peak into our new repository-based
> code-review tool based on Review Board.
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 unimaginatively) MozReview, is
ready for general use.
In the interests of beta-testing our documentation at the same t
17 matches
Mail list logo
