Status

defect
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: ahal, Assigned: ahal)

Tracking

unspecified
mozilla11
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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: nobody → ahalberstadt
Blocks: 703269
Depends on: 703278
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?)
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
Attachment #575297 - Flags: review?(jhammel)
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+
If we do bump versions, then probably immediately before, otherwise we need to push a second change to m-c.
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
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.
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/
https://hg.mozilla.org/mozilla-central/rev/b10b930500f1
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
You need to log in before you can comment on or make changes to this bug.