703266 - Mirror mozbase to m-c

Status: RESOLVED FIXED

(Testing :: Mozbase, defect)

Description

[Andrew Halberstadt [:ahal] (PTO until Oct 10th)]

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"

Comment 1

[Andrew Halberstadt [:ahal] (PTO until Oct 10th)]

Attachment: Patch 1.0 - mirror mozbase to m-c

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

[Jeff Hammel]

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.

Comment 3

[Jeff Hammel]

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.

Comment 4

[Andrew Halberstadt [:ahal] (PTO until Oct 10th)]

If we do bump versions, then probably immediately before, otherwise we need to push a second change to m-c.

Comment 5

[Jeff Hammel]

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

[Mozilla RelEng Bot]

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/[e-mail]-c234b19ebf3e

Comment 7

[cmtalbert]

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.

Comment 8

[Andrew Halberstadt [:ahal] (PTO until Oct 10th)]

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/

Comment 9

[Andrew Halberstadt [:ahal] (PTO until Oct 10th)]

Attachment: Patch 1.1 - Up to date mozbase

Comment 10

[cmtalbert]

Landed on m-i: https://hg.mozilla.org/integration/mozilla-inbound/rev/b10b930500f1

Comment 11

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/b10b930500f1