Closed Bug 787263 Opened 12 years ago Closed 12 years ago

formalize script for mirroring mozbase to m-c

Categories

(Testing :: Mozbase, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 702832

People

(Reporter: k0scist, Unassigned)

Details

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.
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
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
(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?
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
Closed: 12 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.