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)
Testing
Talos
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
| Reporter | ||
Updated•13 years ago
|
Whiteboard: [good first bug][mentor=jhammel][lang=py]
Comment 1•13 years ago
|
||
(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.
| Reporter | ||
Comment 2•13 years ago
|
||
Should we WONTFIX this then?
Comment 3•13 years ago
|
||
(In reply to Jeff Hammel [:jhammel] from comment #2)
> Should we WONTFIX this then?
I would argue so.
| Reporter | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Comment 4•13 years ago
|
||
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?
Comment 5•13 years ago
|
||
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.
Comment 6•13 years ago
|
||
(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.
Description
•