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).
(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
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 702832
You need to log in before you can comment on or make changes to this bug.