Closed
Bug 703266
Opened 10 years ago
Closed 10 years ago
Mirror mozbase to m-c
Categories
(Testing :: Mozbase, defect)
Testing
Mozbase
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla11
People
(Reporter: ahal, Assigned: ahal)
References
Details
Attachments
(2 files)
291.07 KB,
patch
|
k0scist
:
review+
|
Details | Diff | Splinter Review |
292.03 KB,
patch
|
Details | Diff | Splinter Review |
As per discussion, we've decided that mirroring the mozbase repo to m-c is the best approach. "Thank you all for the meeting. Summary: - we agreed that mozbase and peptest will be mirrored to m-c. We'll probably want to do this for many harnesses but can decide that on a case by case basis - the general process: 0. Bump version of the external resource (and release to PyPI if applicable). This is important for a two reasons. The first is sanity. The second is so pegged versions accurately resolve to the software you want them to and there is no possibility of accidentally using the old mirrored version (or any other version, for that matter). 1. resource is mirrored to mozilla-central and a patch created from the diff. A script (e.g. http://k0s.org/mozilla/hg/fetch/file/tip/fetch.py) may be used, or the git repo in m-c methodology, or this can be done by hand. While we should have maintenance/update steps and people should use them, it really doesn't matter how the patch is generated as long as it is correct. 2. Patch is posted to bugzilla for review. On r+, the patch is landed. The version bumping step should actually probably be acted on now instead of when I said it was. - what to do about changes that should be upstreamed? If someone changes the harness on m-c... - firstly, they mostly shouldn't. They should file a bug with a patch of which one of us is aware. We can then fix m-c and upstream simultaneously - we can (and probably should) look at the logs for mirrored resources before clobbering with an updated mirror. If there are changes (though see above point), we can upstream them - and if we do wipe them, that means that someone didn't follow process. Probably not a huge deal as random fixes to harness code (by not us) are uncommon. - after peptest and mozbase pieces are mirrored to m-c, bugs should be filed and acted upon for the duplication of manifestparser.py and mozinfo.py Jeff"
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → ahalberstadt
Assignee | ||
Comment 1•10 years ago
|
||
Adds mozbase to m-c. Notes: 1) I didn't add mozdevice since nothing is using it (personally I'd rather just add it anyway) 2) I included Readmes and test files for the packages (maybe I shouldn't?)
Comment 2•10 years ago
|
||
see also https://bugzilla.mozilla.org/show_bug.cgi?id=702832 Also, please document somewhere on some wiki (e.g. the MozBase page) what you did and how you did it. We will want to update this.
See Also: → 702832
Assignee | ||
Updated•10 years ago
|
Attachment #575297 -
Flags: review?(jhammel)
Comment 3•10 years ago
|
||
Comment on attachment 575297 [details] [diff] [review] Patch 1.0 - mirror mozbase to m-c Well, I didn't audit this to make sure everything was there (I can, if desired), but this looks good to me. Maybe in the future we should do reviews more like a filesystem tree of what is modified (i.e. from `tree`) and the revision of mozbase that was used. Also, assuming this is landed, do we want to bump versions afterwards? Immediately before? Not right now? While its not really part of this bug, we should figure this out.
Attachment #575297 -
Flags: review?(jhammel) → review+
Assignee | ||
Comment 4•10 years ago
|
||
If we do bump versions, then probably immediately before, otherwise we need to push a second change to m-c.
Comment 5•10 years ago
|
||
I think I agree. I guess in general if we stage things on try we should bump between then and the final push. If we bump and push and have to back out we will get a ton of version changes that are unnecessary
Comment 6•10 years ago
|
||
Try run for c234b19ebf3e is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=c234b19ebf3e Results (out of 157 total builds): success: 145 warnings: 9 failure: 3 Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ctalbert@mozilla.com-c234b19ebf3e
None of these warnings are caused by these patches. If the patches on here and bug 703269 are final (I think there is a note needed per comment 2 on 703269) then I can land them on m-i tomorrow. The peptests and mozbase are properly packaged by the makefiles and all seems well. I was able to run the peptests using the mozbase and the peptest harness from the package, so I think we're good to land.
Assignee | ||
Comment 8•10 years ago
|
||
I uploaded a new patch on bug 703269 (https://bugzilla.mozilla.org/show_bug.cgi?id=703269#c3). Note that there are two other commits that also got bundled in that patch, namely the other two on Nov. 22, 2011: https://github.com/mozilla/peptest/commits/master/
Assignee | ||
Comment 9•10 years ago
|
||
Comment 10•10 years ago
|
||
Landed on m-i: https://hg.mozilla.org/integration/mozilla-inbound/rev/b10b930500f1
Comment 11•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b10b930500f1
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
You need to log in
before you can comment on or make changes to this bug.
Description
•