1260781 - fork reviewboard, djblets, and rbtools on github, and update testing, development, and server environments to pull from our forks

Status: RESOLVED FIXED

(MozReview Graveyard :: Infrastructure, defect)

Description

[:glob ✱]

we need to fork reviewboard, djblets, and rbtools on github, and update testing, development, and server environments to pull from our forks instead of the packaged releases.

the changes made on our fork need to be kept to a minimum - its primary use will be to allow us to iterate on upstream modifications before pushing them upstream, as well as removing the "waiting for upstream to release" delays.

it also allows us to insert hooks/events into upstream reviewboard to facilitate our extension should upstream determine they don't want to carry those.

--

https://github.com/mozilla/reviewboard already exists but is long out of date.  i'll chat with our github admins about who has perms, get it updated, and add rbtools and djiblets.

Comment 1

[:glob ✱]

https://github.com/mozilla/reviewboard permissions fixed and updated to upstreanm.
https://github.com/mozilla/djblets and https://github.com/mozilla/rbtools created.
reviewboard group on github updated and set as admin of all three.

Comment 2

[:glob ✱]

i was thinking about this over the weekend; i suspect we'll be better served to bring our fork into vct instead of on github.

this will give us the ability to review and land upstream changes as part of the same review-request/process, as well as removing an external dependency during deployment.

of course it would mean slightly more work to pull in upstream changes and to contribute back upstram (although i'm sure hg-git will do most of the heavy lifting).

:smacleod - thoughts?

Comment 3

[Steven MacLeod [:smacleod]]

(In reply to Byron Jones ‹:glob› from comment #2)
> i was thinking about this over the weekend; i suspect we'll be better served
> to bring our fork into vct instead of on github.

Do you mean having the Review Board and friends code live in version-control-tools, as a directory or something?

> this will give us the ability to review and land upstream changes as part of
> the same review-request/process, as well as removing an external dependency
> during deployment.
> 
> of course it would mean slightly more work to pull in upstream changes and
> to contribute back upstram (although i'm sure hg-git will do most of the
> heavy lifting).
> 
> :smacleod - thoughts?

This does sound nice for a number of reasons, but the pulling in upstream changes part worries me, I have nearly 0 experience with hg-git and I'm not sure exactly how this is going to be structured. I'd be a lot more comfortable with :gps weighing in on this idea.

Comment 4

[Steven MacLeod [:smacleod]]

So something :glob and I were thinking about to manage this stuff and get the best of both worlds would be to have all of the Review Board repo forks live on a separate branch inside vct. This would allow us to use MozReview for reviewing our changes, but also keep a nice linear history of our fork, where we can rebase all of our modifications onto a new head when we pull in updated Review Board code.

:gps, how would you feel about this? Can you think of any better solutions which give us the same benefits?

Comment 5

[Steven MacLeod [:smacleod]]

(In reply to Steven MacLeod [:smacleod] from comment #4)
> :gps, how would you feel about this? Can you think of any better solutions
> which give us the same benefits?

I talked with :gps about this in person. He has concerns about dropping all of the Review Board code and associated repos into vct, forcing everyone to clone them etc. That being said, we were on the same page about using hg, managing our changes as a linear DAG head we rebase as a unit to updated review board commits, and having the code live under a Mozilla property for availability reasons.

I think a good solution would be to create a new mercurial repository dedicated to our Review Board fork, and have it live on hg.mozilla.org. This still gives us the benefit of using MozReview for review and the separation is fine because we really want to isolate changes to the fork anyway.

This does mean our development environment is going to have to support having two repos cloned, and deployment will need to change a bit, but I don't see these being that big of an issue.

:glob, how does this sound to you?

Comment 6

[:glob ✱]

(In reply to Steven MacLeod [:smacleod] from comment #5)
> I think a good solution would be to create a new mercurial repository
> dedicated to our Review Board fork, and have it live on hg.mozilla.org. This
> still gives us the benefit of using MozReview for review and the separation
> is fine because we really want to isolate changes to the fork anyway.
> 
> This does mean our development environment is going to have to support
> having two repos cloned, and deployment will need to change a bit, but I
> don't see these being that big of an issue.

imho vct has always felt like a weird place for mozreview to live, and i agree that as we expand mozreview's scope we're adding a clone burden to all developers.

i love the idea of creating a new repo..

what are your thoughts about moving everything specific to mozreview to this new repo?  we can treat vct as the authoritative location for the libs we share with other parts of vct, but move our review board extensions, autoland,  test suite, development environment, deployment scripts, etc to the new repo where it can live along side the rb/djiblets/rbtools forks.

Comment 7

[Steven MacLeod [:smacleod]]

(In reply to Byron Jones ‹:glob› from comment #6)
> (In reply to Steven MacLeod [:smacleod] from comment #5)
> imho vct has always felt like a weird place for mozreview to live, and i
> agree that as we expand mozreview's scope we're adding a clone burden to all
> developers.
> 
> i love the idea of creating a new repo..
> 
> what are your thoughts about moving everything specific to mozreview to this
> new repo?  we can treat vct as the authoritative location for the libs we
> share with other parts of vct, but move our review board extensions,
> autoland,  test suite, development environment, deployment scripts, etc to
> the new repo where it can live along side the rb/djiblets/rbtools forks.

I'm hesitant to go this far for a couple of reasons:
  a) It seems like a lot of extra work.
  b) We share the "test harness" with all of the other code in vct, which
     would fragment it, having either vct, or our new repo, miss out on
     improvements (Although, you may be suggesting the test harness remains
     in vct and we just use it?)
  c) We lose the separation of our fork / our extensions by them being in
     the same repo (which we could work around by having the fork stuff
     live on a separate branch)
  d) We need to start tracking specific versions of vct for our new repo
     and make sure code changes to any of the libraries we depend on don't
     break us (rather than being forced to fix mozreview when you make a
     change).
  e) We're possibly fragmenting the CI work :rwood is doing, or some of vct
     might miss out on it.

None of these are unsolvable by any means, but it definitely feels like
scope bloat. I think by taking the first step, putting our fork in its
own repo, we aren't cutting ourselves off from migrating in the future
but I don't think we should migrate everything now (Although, I'm not even
100% sure I'd want to in the future).

Thoughts (Back at you with the needinfo :D)?

Comment 8

[:glob ✱]

(In reply to Steven MacLeod [:smacleod] from comment #7)
> I'm hesitant to go this far for a couple of reasons:
> [snip]
> None of these are unsolvable by any means, but it definitely feels like
> scope bloat

fair enough -- i'm happy with limiting it to just review board and friends then.

i'll file blocking bugs to get this set up tonight (if you don't get to it first).

Comment 9

[:glob ✱]

dependencies filed, github forks deleted.

Comment 10

[:glob ✱]

deployed!