formalize script for mirroring mozbase to m-c

VERIFIED DUPLICATE of bug 702832

Status

Testing
Mozbase
VERIFIED DUPLICATE of bug 702832
6 years ago
6 years ago

People

(Reporter: Jeff Hammel, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
See https://wiki.mozilla.org/Auto-tools/Projects/MozBase#Mirroring
and https://wiki.mozilla.org/Auto-tools/HowTo/MirrorRepo

Currently, mirroring to m-c is "a bit much".  The process should
basically be:

- write a bug for mirroring to m-c telling the need why
- generate a diff of tip mozbase vs. m-c
- this is reviewed and pushed to try [*]
- this is landed on m-c if r+ and try success
- once all of that is done, you update the 'mozilla-central' tag on
  mozbase's repo

There are a few things we don't want to mirror, yada yada, but this is
basically the process.  I have a script,
http://k0s.org/mozilla/mozbase/mc-diff.py , that generates a diff.  It
currently does remove hg files removed in git, but other than that it
basically works.

[*] It is important, IMO, to generate a diff of mozbase HEAD vs m-c
tip since we want *both* changes that have been made to m-c and those
made to the github repository to be seen and reviewed by a human being.
This way changes made in m-c that have not been upstream can be
upstreamed. (Which has been several, often without appropriate Mozbase
bugs.)

If we do want to continue mirroring mozbase into mozilla-central
(however see https://bugzilla.mozilla.org/show_bug.cgi?id=787200 )
then I would propose fixing the one known bug in the script and
checking it into mozilla-central and updating the instructions on how
to mirror.
(Reporter)

Comment 1

6 years ago
I'm happy to do the work here but would like to hear what other people think.  If there is too much contention, as usual, my interest will drop dramatically.  And of course if the tide goes to putting talos in m-c, my answer is to also put mozbase in m-c and this will be unneeded.
Didn't we discuss something similar here already? See bug 722451. I think at the time there wasn't a lot of interest in adding this; people (including yourself) seemed to want to solve the problem more generally and/or were satisfied with the fully manual solution.

All that said, I certainly don't have a problem with checking in a script like this (or the one in the old bug) if it makes someone's life easier. We can always iterate and come up with a better long-term solution later.
FWIW, I did a one-off of this so I could update alder, and I started with:
(cd ../mozbase && git archive master) | (cd testing/mozbase && tar x )
rm testing/mozbase/.gitignore
rm -rf testing/mozbase/mozdevice/
rm testing/mozbase/versionbump.py
hg addremove testing/mozbase
(Reporter)

Comment 4

6 years ago
My script doesn't really do much more than that.  Assuming we're keeping mozbase as a separate repo (which I have my doubts on and I know ted amongst many others aren't in favor of anyway), I think tracking the file removal from git is important (which, AIUI, the above script does not do).
Apparently we have 3 bugs open on this, this bug, bug 702832, bug 722451

Comment 6

6 years ago
(In reply to Ted Mielczarek [:ted] from comment #5)
> Apparently we have 3 bugs open on this, this bug, bug 702832, bug 722451

Yeah, can we consolidate the bugs into one bug, and the proposed scripts requirements into one comment?
(Reporter)

Comment 7

6 years ago
As :ctalbert points out in comment 6, we have (count them!) three bugs open on this.  I'm arbitrarily picking the lowest bug number to resolve them against
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 702832
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.