Hope the conclusions in this thread are satisfactory.
Andrew, I apologize for the tense tone in my emails yesterday. I should
have been more chill about it.
On 2/20/13 7:52 PM, Michael Brooks mich...@michaelbrooks.ca wrote:
Sounds awesome Andrew, thanks for the concise recap.
I agree, JIRA
I think so! Thanks everyone for working through this with me.
On Thu, Feb 21, 2013 at 2:08 PM, Filip Maj f...@adobe.com wrote:
Hope the conclusions in this thread are satisfactory.
Andrew, I apologize for the tense tone in my emails yesterday. I should
have been more chill about it.
On
I also think Fil should be more chill ;)
Just kidding, obviously the conclusions are satisfactory. Clearly, writing
is hard.
-Michal
On Thu, Feb 21, 2013 at 2:24 PM, Andrew Grieve agri...@chromium.org wrote:
I think so! Thanks everyone for working through this with me.
On Thu, Feb 21,
Okay, I've interpreted the silence as a just go ahead and merge it and
people will complain if it's broken.
Seeing as we've now cut the next branch, I figured it was a good time to
merge these remaining changes in. So, I did. Please let me know if symbols
aren't working.
On Tue, Feb 12, 2013 at
Andrew did you test it on a device? Don't think hey guys can you test my
changes is a sustainable approach
On 2/20/13 12:19 PM, Andrew Grieve agri...@chromium.org wrote:
Okay, I've interpreted the silence as a just go ahead and merge it and
people will complain if it's broken.
Seeing as we've
Agreed. Please take responsibility and test your code on devices (ideally
not simulators).
If your change impacts multiple platforms, have it tested on those before
pushing to master.
On Wed, Feb 20, 2013 at 12:42 PM, Filip Maj f...@adobe.com wrote:
Andrew did you test it on a device? Don't
I agree with your sentiments, but I think it's impractical in practice. We
have ~11 platforms, and any change to common js affects them all.
In this case, I would need to learn how to build run on webos, tizen, wp7
and windowphone, as well as buying the required hardware to do so. A tall
order
Knowing the implication of your changes is pretty critical.
IMHO everyone who commits to the generic portions of cordova-js should be
prepared to at least smoke test in WP7or8, Android, iOS, and BB. Or at a
bare minimum have extreme confidence that your change will not affect them.
On Wed, Feb
If the can you guys test my changes answer is no, then it'd be great to
hear a no instead of 8 days of silence. That said, I think we'd be able
to move faster if we just took some time to review/test each others'
changes when necessary. We do this when processing pull requests from
external
Good call Mike. Moving this sort of stuff to JIRA (and bringing back to
list when necessary) makes a lot of sense.
On 2/20/13 1:27 PM, Michael Brooks mich...@michaelbrooks.ca wrote:
If the can you guys test my changes answer is no, then it'd be
great to
hear a no instead of 8 days of silence.
I'm trying to imagine what extreem confidence looks like. Flying squirrel suit?
At any rate, hitting iOS, Android, BB, and WP is the min we tend to
test against..
On Wed, Feb 20, 2013 at 1:23 PM, Jesse purplecabb...@gmail.com wrote:
Knowing the implication of your changes is pretty critical.
Agree this sort of thing should live in Jira as sub tasks for ppl to
test. (And yup the CI should help in the future.)
On Wed, Feb 20, 2013 at 1:32 PM, Michal Mocny mmo...@chromium.org wrote:
Agree with where this conversation is going. I do think a call to action
for review is important (esp
Recap:
I tested the common changes against iOS Android and checked them in. I
also checked in the blackberry ones, since they contain better test
coverage in cordova-js than other platforms.
I then emailed out asking if anyone could test the remaining changes on the
branch against WP and webos.
Sounds awesome Andrew, thanks for the concise recap.
I agree, JIRA isn't the ideal solution when considering today's options
around code conversation, but it's what we have as an Apache project. C'est
le vie.
Regardless, if you need a platform to do a task, then JIRA is the answer.
If you need
I've just merged in most of the changes for this (CB-2227). Again, the goal
here was to move all plugin-specific logic out of common files. It's not
the end-game solution, but a step in the right direction.
There are still some changes left on the symbolmapping branch that affect
windows webos.
This is now finished in the branch. There is now *no* plugin logic left in
common.js, nor in any platform.js files.
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/symbolmapping
There is one exception, and that's things like the app plugin, where it's
not really
Pushed up the change with the File plugin being registered in this new way.
Please let me know if you have concerns about it, since the next step is
moving over other plugin APIs, which is boring work :P.
Also, let's move any discussion into the JIRA issue:
This all seems reasonable. Shall we start a branch?
On 1/15/13 2:47 PM, Andrew Grieve agri...@google.com wrote:
Sorry to dump another large email on the list, but I'm hoping this one is
at least less controversial :). I wrote up a plan for moving
module-symbol
mapping out of common.js
Sorry to dump another large email on the list, but I'm hoping this one is
at least less controversial :). I wrote up a plan for moving module-symbol
mapping out of common.js platform.js and into individual plugins.
If you have feedback/comments, let me know.
* Goals:
- Change from listing
19 matches
Mail list logo
