Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
devicemanager in mozbase/mozdevice vs. mozilla-central
14 views
Skip to first unread message
William Lachance
Jan 9, 2012, 12:24:23 PM1/9/12
to to...@lists.mozilla.org, Jeff Hammel, Joel Maher, Geoffrey Brown, Clint Talbert
Heya,
So a few months ago I split off the devicemanager python modules from mozilla-central into mozbase so the functionality could be used in things outside of the main mozilla-central tree:
https://github.com/mozilla/mozbase/tree/master/mozdevice
Currently this module is used by eideticker and talos, with a few more things in the future. Unfortunately and perhaps predictably, there's now a bit of confusion as to where changes to these files should go. Most patches are still landing in mozilla-central, e.g.:
https://bugzilla.mozilla.org/show_bug.cgi?id=705175
https://bugzilla.mozilla.org/show_bug.cgi?id=716077
However some minor changes are also being committed inside mozbase:
https://bugzilla.mozilla.org/show_bug.cgi?id=713970
If we don't stay on top of the difference between these files, it's going to be difficult to merge/reconcile changes between them. I guess there's three possible approaches:
1. Land changes in mozbase, then periodically sync to mozilla-central. I believe this is what we're doing with some other parts of mozbase (mozprofile, mozrunner) used by the forthcoming peptest framework.
2. Land changes in mozilla-central, then periodically sync to mozbase.
3. Land changes in both, and synchronize them patch by patch after-the-fact.
(1) makes the most sense to me
(2) is probably most palatable to developers who don't want to know/think about mozbase
(3) sounds like a recipe for confusion (what if some of our patches conflict?)
At the moment, I don't really have a strong preference for (1) vs. (2). I think some variant of (1) is the only option that will make sense long term, as more projects start depending on mozbase -- but if people want to just use mozdevice as a dumping ground for changes in m-c for now, that's also fine with me. The important thing IMO is that we pick one or the other and stick to it.
Thoughts?
Will
So a few months ago I split off the devicemanager python modules from mozilla-central into mozbase so the functionality could be used in things outside of the main mozilla-central tree:
https://github.com/mozilla/mozbase/tree/master/mozdevice
Currently this module is used by eideticker and talos, with a few more things in the future. Unfortunately and perhaps predictably, there's now a bit of confusion as to where changes to these files should go. Most patches are still landing in mozilla-central, e.g.:
https://bugzilla.mozilla.org/show_bug.cgi?id=705175
https://bugzilla.mozilla.org/show_bug.cgi?id=716077
However some minor changes are also being committed inside mozbase:
https://bugzilla.mozilla.org/show_bug.cgi?id=713970
If we don't stay on top of the difference between these files, it's going to be difficult to merge/reconcile changes between them. I guess there's three possible approaches:
1. Land changes in mozbase, then periodically sync to mozilla-central. I believe this is what we're doing with some other parts of mozbase (mozprofile, mozrunner) used by the forthcoming peptest framework.
2. Land changes in mozilla-central, then periodically sync to mozbase.
3. Land changes in both, and synchronize them patch by patch after-the-fact.
(1) makes the most sense to me
(2) is probably most palatable to developers who don't want to know/think about mozbase
(3) sounds like a recipe for confusion (what if some of our patches conflict?)
At the moment, I don't really have a strong preference for (1) vs. (2). I think some variant of (1) is the only option that will make sense long term, as more projects start depending on mozbase -- but if people want to just use mozdevice as a dumping ground for changes in m-c for now, that's also fine with me. The important thing IMO is that we pick one or the other and stick to it.
Thoughts?
Will
Jeff Hammel
Jan 9, 2012, 12:28:43 PM1/9/12
to William Lachance, Joel Maher, Geoffrey Brown, Clint Talbert, to...@lists.mozilla.org
a big +1 to option 1. We may need to backport patches from m-c if anyone
lands there (which really no one should), but 1. still seems like a
clear win IMHO (and in accordance with what we discussed last quarter
wrt mirroring mozbase [etc] to m-c).
lands there (which really no one should), but 1. still seems like a
clear win IMHO (and in accordance with what we discussed last quarter
wrt mirroring mozbase [etc] to m-c).
Joel Maher
Jan 9, 2012, 9:25:19 PM1/9/12
to Jeff Hammel, Geoffrey Brown, William Lachance, Clint Talbert, to...@lists.mozilla.org
Developers will be writing code for mozilla-central and there is no way around that. We have been keeping stuff in parity for a while between m-c and talos and it works out pretty easy. Basically we find a master source to land on and if something is landing elsewhere we mirror it. Otherwise we do a diff once in a while and get them up to date.
I propose m-c is the master source for devicemanager*. This avoid confusion as more people are running tests and hacking from their android builds. If there is a need for major changes in the mozdevice repository I could consider switching. My impression is mozdevice is mostly done and stable.
-Joel
I propose m-c is the master source for devicemanager*. This avoid confusion as more people are running tests and hacking from their android builds. If there is a need for major changes in the mozdevice repository I could consider switching. My impression is mozdevice is mostly done and stable.
-Joel
William Lachance
Jan 10, 2012, 11:08:17 AM1/10/12
to Joel Maher, Geoffrey Brown, Jeff Hammel, Clint Talbert, to...@lists.mozilla.org
On 12-01-09 09:25 PM, Joel Maher wrote:
> Developers will be writing code for mozilla-central and there is no way around that. We have been keeping stuff in parity for a while between m-c and talos and it works out pretty easy. Basically we find a master source to land on and if something is landing elsewhere we mirror it. Otherwise we do a diff once in a while and get them up to date.
Yup, no matter what we do changes to devicemanager* will have to be
> Developers will be writing code for mozilla-central and there is no way around that. We have been keeping stuff in parity for a while between m-c and talos and it works out pretty easy. Basically we find a master source to land on and if something is landing elsewhere we mirror it. Otherwise we do a diff once in a while and get them up to date.
tested against mozilla-central. The question is where stuff should land:
m-c, mozbase, or both.
If we decided mozbase/mozdevice was going to be the canonical location,
workflow for hacking on devicemanager* would probably look like this:
1. Modify devicemanager* in m-c, push to try, make sure things still
work, get review, etc.
2. Apply your patch to devicemanager* to mozbase/mozdevice, push to our
github repo.
3. Sync mozbase/mozdevice in m-c with github repo.
On the other hand, if we are going to make m-c the first place to put
stuff, I guess the workflow looks like this instead:
1. Modify devicemanager* in m-c, push to try, make sure things work, get
review, etc.
2. Push changes to m-c.
We would then just periodically sync the copies of devicemanager* in m-c
with mozbase (much like we were doing before with talos, as you say). I
can see how this is simpler for developers who don't want to have to
care about mozbase, but as Jeff pointed out it is
totally different from everything else we're doing with that project.
That argues against it, but if the pros outweigh the cons, fine (IMO).
The one situation I want to avoid is to have random patches flying into
both repositories on an adhoc basis, which is what just happened with
https://bugzilla.mozilla.org/show_bug.cgi?id=713970.
> I propose m-c is the master source for devicemanager*. This avoid confusion as more people are running tests and hacking from their android builds. If there is a need for major changes in the mozdevice repository I could consider switching. My impression is mozdevice is mostly done and stable.
interface at this point. Some of the implementation details for the SUT
and ADB variants could probably be better but I think the interface is
about as good as it gets given Android's limitations.
Will
Jeff Hammel
Jan 10, 2012, 11:28:45 AM1/10/12
to Joel Maher, Geoffrey Brown, William Lachance, Clint Talbert, to...@lists.mozilla.org
Is this just for devicemanager or are we considering this for more of
mozbase?
On 01/09/2012 06:25 PM, Joel Maher wrote:
> Developers will be writing code for mozilla-central and there is no way around that. We have been keeping stuff in parity for a while between m-c and talos and it works out pretty easy. Basically we find a master source to land on and if something is landing elsewhere we mirror it. Otherwise we do a diff once in a while and get them up to date.
>
mozbase?
On 01/09/2012 06:25 PM, Joel Maher wrote:
> Developers will be writing code for mozilla-central and there is no way around that. We have been keeping stuff in parity for a while between m-c and talos and it works out pretty easy. Basically we find a master source to land on and if something is landing elsewhere we mirror it. Otherwise we do a diff once in a while and get them up to date.
>
> I propose m-c is the master source for devicemanager*. This avoid confusion as more people are running tests and hacking from their android builds. If there is a need for major changes in the mozdevice repository I could consider switching. My impression is mozdevice is mostly done and stable.
>
> -Joel
>
Clint Talbert
Jan 10, 2012, 11:37:45 AM1/10/12
to Jeff Hammel, Joel Maher, Geoffrey Brown, William Lachance, to...@lists.mozilla.org
Just for devicemanager.
We have been keeping mozilla-central as *the* canonical location for
devicemanager* for years now. It's been mirrored to other repos out of
necessity (because it was technically the first of the mozbase utilities).
I'm with Joel. I think we take option 2 and and port changes from m-c
into mozbase for devicemanager* utilities. I know this is backwards for
those of us working on mozbase, but right now there are many more people
working on devicemanager* utilities than on mozbase specifically, and I
don't want to disrupt their work flows when we're under the gun to get
android automation rolled out. Once the current round of android
automation is done, we can revisit.
Clint
We have been keeping mozilla-central as *the* canonical location for
devicemanager* for years now. It's been mirrored to other repos out of
necessity (because it was technically the first of the mozbase utilities).
I'm with Joel. I think we take option 2 and and port changes from m-c
into mozbase for devicemanager* utilities. I know this is backwards for
those of us working on mozbase, but right now there are many more people
working on devicemanager* utilities than on mozbase specifically, and I
don't want to disrupt their work flows when we're under the gun to get
android automation rolled out. Once the current round of android
automation is done, we can revisit.
Clint
Geoffrey Brown
Jan 10, 2012, 11:44:57 AM1/10/12
to Clint Talbert, Joel Maher, Jeff Hammel, William Lachance, to...@lists.mozilla.org
I can certainly work with either option 1 or option 2, but option 2 is more natural for me, and one less complication for "visiting developers" who want to contribute to devicemanager but don't know much about mozbase.
- Geoff
- Geoff
0 new messages