Add a .reviewboardrc file to mozilla-central

RESOLVED FIXED in mozilla28

Status

()

Core
General
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: gps, Assigned: gps)

Tracking

Trunk
mozilla28
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
There is a somewhat official Mozilla-hosted ReviewBoard instance now available. We should add a .reviewboardrc file to mozilla-central to make integration with RBTools seamless.

http://mrcote.info//blog/2013/11/26/reviewboard/
(Assignee)

Comment 1

5 years ago
And I'm already running into RBTools bugs while attempting to upload this patch to ReviewBoard. I may need to educate RBTools about how Mercurial works. Sadness.
(Assignee)

Comment 2

5 years ago
Created attachment 8339071 [details] [diff] [review]
Add a .reviewboardrc file

This should do it. Review not on ReviewBoard out of irony and RBTools +
Mercurial stupidity.
Attachment #8339071 - Flags: review?(josh)
(Assignee)

Updated

5 years ago
Assignee: nobody → gps
Status: NEW → ASSIGNED

Comment 3

5 years ago
Comment on attachment 8339071 [details] [diff] [review]
Add a .reviewboardrc file

Review of attachment 8339071 [details] [diff] [review]:
-----------------------------------------------------------------

I'm just an enthusiast; I don't actually know anything about setting this up correctly.
Attachment #8339071 - Flags: review?(josh) → review?(mconley)
No longer blocks: 515210
Comment on attachment 8339071 [details] [diff] [review]
Add a .reviewboardrc file

Review of attachment 8339071 [details] [diff] [review]:
-----------------------------------------------------------------

::: .reviewboardrc
@@ +1,5 @@
> +# This Source Code Form is subject to the terms of the Mozilla Public
> +# License, v. 2.0. If a copy of the MPL was not distributed with this
> +# file, You can obtain one at http://mozilla.org/MPL/2.0/.
> +
> +REPOSITORY = 'mozilla-central'

I wonder if we should make REPOSITORY a little smarter - I imagine if one is posting a review request from a mozilla-inbound clone for example, they'd like it to be applied to the mozilla-inbound repository on Review Board.

Same goes for mozilla-aurora and mozilla-beta, if those eventually get added to the list of repositories on Review Board.

Perhaps the value of REPOSITORY could somehow be the output from `hg path default`?
Hey Steven - you're the RBTools guy, is the above feasible / advisable?
Flags: needinfo?(smacleod)
(In reply to Mike Conley (:mconley) from comment #4)
> I wonder if we should make REPOSITORY a little smarter - I imagine if one is
> posting a review request from a mozilla-inbound clone for example, they'd
> like it to be applied to the mozilla-inbound repository on Review Board.
> 
> Same goes for mozilla-aurora and mozilla-beta, if those eventually get added
> to the list of repositories on Review Board.
> 
> Perhaps the value of REPOSITORY could somehow be the output from `hg path
> default`?

We'll also have problems with developers using git clones, since they'll need there patches to be applied against "gecko-dev" in Review Board.

There are a few options here:

1) Leave REPOSITORY undefined. RBTools will then just try and use the clone path of your local clone to identify which repository the patch applies to. As long as the developer cloned from the same path that Review Board did (including http vs ssh etc.) things will work.

2) Introduce a .reviewboardrc to each repository with differing REPOSITORY values. i.e Just have a different version of the file in mozilla-inbound etc. I'm not sure we can take care of the git clones in this case though.

3) Abuse the fact .reviewboardrc is really just Python. This is kind of an undocumented "feature" that .reviewboardrc files are executed python (This is for historical reasons, and may change at some point in the future, but this isn't planned anytime soon). So really, we could be as smart as we need and run any python code which sets REPOSITORY to the correct thing.

I feel like 3 is probably our best bet. With some simple scripting we should be able to take care of all the configurations.
Flags: needinfo?(smacleod)
Comment on attachment 8339071 [details] [diff] [review]
Add a .reviewboardrc file

Review of attachment 8339071 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Steven MacLeod [:smacleod] from comment #6)
> (In reply to Mike Conley (:mconley) from comment #4)
> > I wonder if we should make REPOSITORY a little smarter - I imagine if one is
> > posting a review request from a mozilla-inbound clone for example, they'd
> > like it to be applied to the mozilla-inbound repository on Review Board.
> > 
> > Same goes for mozilla-aurora and mozilla-beta, if those eventually get added
> > to the list of repositories on Review Board.
> > 
> > Perhaps the value of REPOSITORY could somehow be the output from `hg path
> > default`?
> 
> We'll also have problems with developers using git clones, since they'll
> need there patches to be applied against "gecko-dev" in Review Board.
> 
> There are a few options here:
> 
> 1) Leave REPOSITORY undefined. RBTools will then just try and use the clone
> path of your local clone to identify which repository the patch applies to.
> As long as the developer cloned from the same path that Review Board did
> (including http vs ssh etc.) things will work.
> 
> 2) Introduce a .reviewboardrc to each repository with differing REPOSITORY
> values. i.e Just have a different version of the file in mozilla-inbound
> etc. I'm not sure we can take care of the git clones in this case though.
> 
> 3) Abuse the fact .reviewboardrc is really just Python. This is kind of an
> undocumented "feature" that .reviewboardrc files are executed python (This
> is for historical reasons, and may change at some point in the future, but
> this isn't planned anytime soon). So really, we could be as smart as we need
> and run any python code which sets REPOSITORY to the correct thing.
> 
> I feel like 3 is probably our best bet. With some simple scripting we should
> be able to take care of all the configurations.

Alright, if that's the case, how about we land this .reviewboardrc with just the REVIEWBOARD_URL defined (which puts us in the state of (1)), and then file a separate bug to figure out (3)?
Attachment #8339071 - Flags: review?(mconley) → review+
(Assignee)

Comment 8

5 years ago
Yeah, I think making this an evaled script with added smarts (3) is the best solution. But something is better than nothing. I'll land this with just REVIEWBOARD_URL defined.
https://hg.mozilla.org/mozilla-central/rev/11f9ec6184b2
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
(Assignee)

Updated

4 years ago
Blocks: 1103052
You need to log in before you can comment on or make changes to this bug.