Closed Bug 740839 Opened 13 years ago Closed 13 years ago

create_talos_zip.py should point to the canonical m-c sources for devicemanager

Categories

(Testing :: Talos, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: k0scist, Unassigned)

Details

(Whiteboard: [good first bug][mentor=jhammel][lang=py])

mozdevice now canonically lives in mozilla-central and is mirrored backwards to github: https://wiki.mozilla.org/Auto-tools/Projects/MozBase#Android_Device_Access_-_MozDevice create_talos_zip.py should point to the canonical source for these files: http://hg.mozilla.org/build/talos/file/77b823710ff6/create_talos_zip.py#l22 (In addition, a little script cleanup would be nice) Not sure if we should be mirroring other files here as well
Whiteboard: [good first bug][mentor=jhammel][lang=py]
(In reply to Jeff Hammel [:jhammel] from comment #0) > mozdevice now canonically lives in mozilla-central and is mirrored > backwards to github: > > https://wiki.mozilla.org/Auto-tools/Projects/MozBase#Android_Device_Access_- > _MozDevice > > create_talos_zip.py should point to the canonical source for these > files: > > http://hg.mozilla.org/build/talos/file/77b823710ff6/create_talos_zip.py#l22 > > (In addition, a little script cleanup would be nice) > > Not sure if we should be mirroring other files here as well Note that given the way talos imports devicemanager, we currently depend on an __init__.py which is only in the github repo. The whole goal of creating mozdevice was to have a central place for software like Talos to pull down a known-stable version of devicemanager (similar to what we're planning to do with mozbase as a whole). If I were going to change anything about how we create talos.zip, I would focus on pulling down a specific revision of mozdevice (as opposed to tip/master), so situations like bug 739766 don't crop up again. Pulling devicemanager from m-c is likely to make things *more* unstable, not less. I assume eventually we'll be getting mozdevice/mozbase directly from PyPI (or an internal mirror of PyPI) which will make this whole conversation moot.
Should we WONTFIX this then?
(In reply to Jeff Hammel [:jhammel] from comment #2) > Should we WONTFIX this then? I would argue so.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
We want to make sure talos and unittests run the same version of devicemanagerSUT.py. We also want to provide a uniform location for sut_tools to use. With all of this, I am fine with using an internal pypi, but I don't know how we would use that for unittests from m-c. Suggestions?
Remember that whenever you drop a new talos.zip with talos.json you could hit whatever issues get introduced into devicemanager* on git (where there is no continuous integration). If you took a known good version that might reduce issues when you run a new talos.zip through the try server. Right now, I am grabbing devicemanager from m-c (hg web) for running my updateSUT.py script while unit tests are using what comes inside of talos.zip (which indirectly comes from git) and other parts use the older versions on talos (hg web). I am flexible about what you choose but I need a one source of truth.
(In reply to Joel Maher (:jmaher) from comment #4) > We want to make sure talos and unittests run the same version of > devicemanagerSUT.py. We also want to provide a uniform location for > sut_tools to use. > > With all of this, I am fine with using an internal pypi, but I don't know > how we would use that for unittests from m-c. Suggestions? This is really the same discussion that we've had before about how do we get mozilla-central using mozbase. The exact issues that apply to this will apply to mozinfo, mozprofile, etc. This has been discussed in depth over the past year (since before I even started working on this stuff). I don't think I have anything new to add to that discussion at this point, aside from highlighting the fact that maintaining the same package in two different places has proven to be *really confusing* (as Armen just noticed). I've tried to mitigate this problem by insisting that people only commit/send patches for devicemanager to mozilla-central, but there's still the question of what people should be using in projects that live outside the tree (sut_tools, talos, eideticker, autophone, ...). We discussed this earlier in the year in mozilla.tools (see the thread "devicemanager in mozbase/mozdevice vs. mozilla-central"). Maybe it's time to consider revisiting our decision.
You need to log in before you can comment on or make changes to this bug.