Hi Jukka,
We've vetted all the incubator pull requests. All of the incubator-cordova
repos can be removed now. We used an issue to help organize:
https://issues.apache.org/jira/browse/CB-2417
Thanks,
Shaz
On Tue, Dec 11, 2012 at 2:27 PM, Jukka Zitting wrote:
> Hi,
>
> On Fri, Dec 7, 2012 at 10:
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 to
Ah, somehow I missed that step when I changed email accounts. Thanks Shaz!
On Wednesday, February 20, 2013, Shazron wrote:
> Isn't it refreshing? Subscribe to iss...@cordova.apache.org now.
>
> On Wednesday, February 20, 2013, Kevin Hawkins wrote:
>
> > Does anyone else not get JIRA bugs copied
Isn't it refreshing? Subscribe to iss...@cordova.apache.org now.
On Wednesday, February 20, 2013, Kevin Hawkins wrote:
> Does anyone else not get JIRA bugs copied to the mailing list anymore, or
> is that just me? I used to get them, but then my Cordova mailing list
> behavior has always been a
While investigating this irritating issue
(https://issues.apache.org/jira/browse/CB-2085), I found that when we
first open the database, we are using the built-in WebKit Database,
but once I go into child browser and go back, we start to use the
Storage plugin. Does anyone remember which scenarios
Done. https://issues.apache.org/jira/browse/CB-2507
-- Marcel Kinard
On Feb 20, 2013, at 5:46 PM, Shazron wrote:
> I didn't get to write upgrade instructions in time. It'll definitely be in
> the final 2.5.0 - and yup an issue filed would be great :)
>
>
> On Wed, Feb 20, 2013 at 2:42 PM, Mar
I've tagged BlackBerry but the media tests still crash the mobile spec auto
test. Not much we can do about this right now since we're still waiting on
BlackBerry to get back to us on this issue:
https://github.com/blackberry/BB10-WebWorks-Framework/issues/606
It also might be the case that this is
I didn't get to write upgrade instructions in time. It'll definitely be in
the final 2.5.0 - and yup an issue filed would be great :)
On Wed, Feb 20, 2013 at 2:42 PM, Marcel Kinard wrote:
> Related to CB-2323, I was looking to see if the Upgrading instructions for
> 2.5.0 included some verbage
Related to CB-2323, I was looking to see if the Upgrading instructions for
2.5.0 included some verbage about the name change to for config.xml.
I'm not seeing any upgrade instructions for 2.5.0. The latest verbage in there
is for upgrading to 2.4.0.
Is this an oversight, considering we are at
CurrentStatus: Resolved my cordova-js issues for WP7, (pulled too many
changes in)
WP7 it has been tagged.
Moving on to WP8.
On Wed, Feb 20, 2013 at 1:46 PM, Shazron wrote:
> Alright, the two iOS errors (compass error, FileTransfer body error) are
> deemed harmless, so I will check in the cordov
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.
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 wrote:
> Agree with where this conversation is going. I do think a "call to action"
> for review is important (esp given the number
Alright, the two iOS errors (compass error, FileTransfer body error) are
deemed harmless, so I will check in the cordova-js for iOS for 2.5.0rc1,
and tag iOS 2.5.0rc1.
On Wed, Feb 20, 2013 at 1:27 PM, Jesse wrote:
> CompassHeading is not an exposed API, and I had planned to remove the tests
> f
Agree with where this conversation is going. I do think a "call to action"
for review is important (esp given the number of platforms) and perhaps
JIRA isn't the absolute worst way to do it ;)
Another question: Are there plans to expand CI to other platforms? Support
requesting tests for a remot
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 wrote:
> Knowing the implication of your changes is pretty critical.
> IMHO everyone who commi
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" 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. That sai
Agree with this. Sending out testing requests is fine, invariably not
everyone has a device for every platform. That said, this does not
exonerate anyone from not testing.
So in terms of the symbol mapping stuff, my question still stands: did you
test it on a device? If so, which device? Based on
CompassHeading is not an exposed API, and I had planned to remove the tests
for it.
However, there are numerous places where it is used ( throughout
cordova-js, I don't believe any native code depends on it's existence )
https://issues.apache.org/jira/browse/CB-1583
ideally duck typing of the valu
>
> 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
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 20
The compass error is introduced from Gord's latest change.
The test that is failing is:
if you create a new CompassHeading object with no parameters, it should
have defined properties.
This commit:
https://github.com/apache/cordova-js/commit/6133a7e05bcd2ddc4a15591cf79cda9
65cbaf1ab
Breaks t
Current status,
Investigating why absolutely nothing is working in WP7 an WP8 with recent
updates to cordova-js. DeviceReady is not even firing
On Wed, Feb 20, 2013 at 12:44 PM, Shazron wrote:
> The FileTransfer errors should go away once I check in the updated js,
> which leaves the compas
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 f
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 wrote:
> Andrew did you test it on a device? Don't think "hey guys
The FileTransfer errors should go away once I check in the updated js,
which leaves the compass stuff. I'll investigate the compass stuff before
committing the updated js.
On Wed, Feb 20, 2013 at 12:40 PM, Filip Maj wrote:
> The FileTransferError body property is not implemented yet so that err
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" 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 now cut the
The FileTransferError body property is not implemented yet so that error
is fine.
The bugs blocking RC are:
- The compass ones are new, we should investigate
- The FileTransfer is not defined, which was a symbol mapping issue in the
JS (which is why all platforms need to grab the new JS test).
On
Yeah I see those too:
http://ci.cordova.io/
Click on the outer donut sections for the stack trace / failing errors...
On 2/20/13 12:33 PM, "Becky Gibson" wrote:
>On iOS I'm failing one of the compass tests: CompassHeading should be
>able
>to create a new CompassHeading with no parameters.
>
Don't think these failures should block rc1, but on iOS, I'm getting that
plus:
Compass (navigator.compass) Compass Heading model (CompassHeading) should
be able to create a new CompassHeading instance with no
parameters.
Expected undefined to be defined.
Expected undefined to be defined.
Expec
On iOS I'm failing one of the compass tests: CompassHeading should be able
to create a new CompassHeading with no parameters.
On Wed, Feb 20, 2013 at 3:07 PM, Filip Maj wrote:
> K I've updated the JS tag. Platforms should grab the latest 2.5.0rc1 tag
> from cordova-js and retag + retest.
>
>
Thanks Fil. Was just wanting someone to sanity check it before re-tagging,
but we can always re-re-tag :)
On Wed, Feb 20, 2013 at 3:07 PM, Filip Maj wrote:
> K I've updated the JS tag. Platforms should grab the latest 2.5.0rc1 tag
> from cordova-js and retag + retest.
>
> On 2/20/13 12:02 PM, "
Right, that makes sense. In our specific case with all projects having a
VERSION file it should be a commit but I understand your point :)
On 2/20/13 11:55 AM, "Michal Mocny" wrote:
>Fil: yes, that graph looks correct, with the added note that your rc/final
>point release "commits" are conceptua
Also: Fil you are totally correct that this flow only really helps with
split-stream dev, but considering how long it takes and often it happens
(code freeze due to release) this seems kind of necessary. I think it is
also a great foundation for automating packaging and tagging. So lets work
on t
Fil: yes, that graph looks correct, with the added note that your rc/final
point release "commits" are conceptually just tags. Its possible those
also accompany a commit to change some versioning changes in text files,
I'm not sure, but not necessarily.
-Michal
On Wed, Feb 20, 2013 at 2:47 PM,
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 a
Not clear (?) but I think so. I suppose all platforms get the new js and
re-test, and re-tag.
On Wed, Feb 20, 2013 at 11:53 AM, Filip Maj wrote:
> So the JS needs to be retagged ya?
>
> On 2/20/13 11:03 AM, "Andrew Grieve" wrote:
>
> >Not this time actually. This was a refactor in cordova-js
I agree that it is necessary. Just want to make clear that split stream
dev won't speed up the release process (as the thread title implies).
On 2/20/13 11:57 AM, "Michal Mocny" wrote:
>Also: Fil you are totally correct that this flow only really helps with
>split-stream dev, but considering how
K I've updated the JS tag. Platforms should grab the latest 2.5.0rc1 tag
from cordova-js and retag + retest.
On 2/20/13 12:02 PM, "Shazron" wrote:
>Not clear (?) but I think so. I suppose all platforms get the new js and
>re-test, and re-tag.
>
>
>
>On Wed, Feb 20, 2013 at 11:53 AM, Filip Maj w
Fil - looks right to me.
Added the git commands for committing into next to the wiki:
git checkout next
git pull apache
git checkout topic_branch
git rebase next -i
git checkout next
git merge --ff-only topic_branch
git push apache next
git branch -d topic_branch
git checkout master
git merge ne
So the JS needs to be retagged ya?
On 2/20/13 11:03 AM, "Andrew Grieve" wrote:
>Not this time actually. This was a refactor in cordova-js where I forgot
>to
>"git add" the new files. It broke all existing tests.
>
>
>On Wed, Feb 20, 2013 at 1:37 PM, Michal Mocny wrote:
>
>> Huzzah!
>>
>> I take
Shaz sums it up perfect. Once we cut 'next' nothing goes in unless its
critical to it being a good release. Anything that goes into next should
almost by definition also go in to master.
Note that this is functionally the same as only ever pushing to master, and
cherry-picking certain commits in
So when we release a final point release (that is a culmination of rcs,
i.e. 2.5.0rc1->2.5.0rc2->2.5.0), at that point on the next branch
effectively stops being in use.
ASCII graph incoming of potential scenario
Master Branch o--E---o--o--o--o--o--o--o--o
\/ / /
http://cl.ly/MOrD
Master always has all the changes. Next will never have experimental
changes/features after next is created, just bug fixes.
On Wednesday, February 20, 2013, Joe Bowser wrote:
> Honestly, this process is too complex and we should just go back to
> what we were doing before. I
Honestly, this process is too complex and we should just go back to
what we were doing before. I don't think our git flow was what is
slowing us down.
On Wed, Feb 20, 2013 at 11:22 AM, Filip Maj wrote:
> Ok so the flow is: if you are committing into next, always merge into
> master. Good. So t
Ok so the flow is: if you are committing into next, always merge into
master. Good. So the CI setup doesn't need to differentiate between master
and next. It can always pull from master.
On 2/20/13 11:04 AM, "Andrew Grieve" wrote:
>Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
>
Step 5 here: http://wiki.apache.org/cordova/CommitterWorkflow
Probably it should be "isFixingRegression" instead of "isBugFix". I'll
update it now.
On Wed, Feb 20, 2013 at 1:59 PM, Filip Maj wrote:
> I noticed on iOS the commits going into next are mirrored on master.
>
> For Android that was
Not this time actually. This was a refactor in cordova-js where I forgot to
"git add" the new files. It broke all existing tests.
On Wed, Feb 20, 2013 at 1:37 PM, Michal Mocny wrote:
> Huzzah!
>
> I take it you pushed mobile spec test changes without the cordova-js code
> needed for them to pas
I noticed on iOS the commits going into next are mirrored on master.
For Android that was not done.
What is the correct process?
On 2/20/13 10:12 AM, "Michal Mocny" wrote:
> I didn't know that. Thanks!
>
>
>On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson
>wrote:
>
>> Thank you, Michael! I
Huzzah!
I take it you pushed mobile spec test changes without the cordova-js code
needed for them to pass? This is the downside of multi-repo :(
-Michal
On Wed, Feb 20, 2013 at 1:33 PM, Andrew Grieve wrote:
> Okay, checked them into next branch, and merged them into master as well.
>
> Likel
Okay, checked them into next branch, and merged them into master as well.
Likely filetransfer is broken on all platforms without these files.
On Wed, Feb 20, 2013 at 1:31 PM, Andrew Grieve wrote:
> I think I've figured it out:
>
> agrieve@agrieve-macbookpro ~/git/cordova-js (next) $ git status
I think I've figured it out:
agrieve@agrieve-macbookpro ~/git/cordova-js (next) $ git status
# On branch next
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# lib/common/plugin/filetransfer/
# lib/windowsphone/plugin/filetransfer/
nothing added to commit but untr
I didn't know that. Thanks!
On Wed, Feb 20, 2013 at 1:10 PM, Becky Gibson wrote:
> Thank you, Michael! I do usually go a git push --dry-run to check that I
> am pushing what I expect but I'll try the diff as well.
>
>
> On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny wrote:
>
> > So there
Thank you, Michael! I do usually go a git push --dry-run to check that I
am pushing what I expect but I'll try the diff as well.
On Wed, Feb 20, 2013 at 1:07 PM, Michal Mocny wrote:
> So there is also http://wiki.apache.org/cordova/CuttingReleases which may
> be useful (esp Taggin section).
>
For added data, I also fail using the tagged cordova-js
(04e4ceafdcd59cdd937e873cc9006766c1e5940a) built locally.
On Wed, Feb 20, 2013 at 12:40 PM, Shazron wrote:
> I just generated the js from cordova-js on tag 2.5.0rc1 (hash
> 04e4ceafdcd59cdd937e873cc9006766c1e5940a) and I get the same res
So there is also http://wiki.apache.org/cordova/CuttingReleases which may
be useful (esp Taggin section).
As far as the confusion with the two branch names: "topic_branch" is your
local working branch for a bugfix/feature, and "to_be_merged" is really
"temporary_new_name_for_a_branch_to_do_rebase_
Hey Jeffrey, I'm sorry but I'm not convinced by 'its cleaner' as an
argument. Its not. Its a specific version number to a specific SDK. I
understand that you have more than one SDK: this is common in mobile
platforms, and addressed by the current repo.
Can you be more precise and explain exactly w
Can someone please provide a "git cordova release process for dummies"
example to make sure I do the release commits and merges properly (the
committerWorkflow example didn't help me as I didn't understand the
topic_branch and to_be_merged distinction)
At any rate, can I do a git checkout apache n
I just generated the js from cordova-js on tag 2.5.0rc1 (hash
04e4ceafdcd59cdd937e873cc9006766c1e5940a) and I get the same results as
I've always had :/
On Wed, Feb 20, 2013 at 9:34 AM, Andrew Grieve wrote:
> Using the JS built from cordova-js it's working fine...
>
>
> On Wed, Feb 20, 2013 at 1
Using the JS built from cordova-js it's working fine...
On Wed, Feb 20, 2013 at 12:32 PM, Shazron wrote:
> Could be the symbol mapping.
> Using Safari 6 iPhone Simulator debugging -- window.FileTransfer is not
> defined, but I can do a cordova.require("cordova/plugin/FileTransfer").
>
>
> On We
aha! Okay, did a pull and using the cordova.ios.js from cordova-ios it now
breaks.
On Wed, Feb 20, 2013 at 12:27 PM, Shazron wrote:
> Don't know what's wrong - with mob-spec 3e3d075 on iOS 2.5.0rc1 it still
> all fails. Trying iOS 2.4.0 (with latest mob-spec), it all passes. I
> suspect its in
Could be the symbol mapping.
Using Safari 6 iPhone Simulator debugging -- window.FileTransfer is not
defined, but I can do a cordova.require("cordova/plugin/FileTransfer").
On Wed, Feb 20, 2013 at 9:27 AM, Shazron wrote:
> Don't know what's wrong - with mob-spec 3e3d075 on iOS 2.5.0rc1 it still
Don't know what's wrong - with mob-spec 3e3d075 on iOS 2.5.0rc1 it still
all fails. Trying iOS 2.4.0 (with latest mob-spec), it all passes. I
suspect its in the cordova-js, not mob-spec
On Wed, Feb 20, 2013 at 9:17 AM, Shazron wrote:
> Andrew, I re-verified and re-downloaded 2.5.0rc1 of iOS and
Andrew, I re-verified and re-downloaded 2.5.0rc1 of iOS and 2.5.0rc1 of
mobile-spec, created a new project - I get the same results as I had (both
in Simulator and device as well).
On Wed, Feb 20, 2013 at 8:46 AM, Andrew Grieve wrote:
> Just tried the tests and they are all passing for me (on
Thanks guys. I'll file a bug, and should have a pull request shortly.
Andrew, for the record, I didn't see anything particular in Jira around
public symbols maintenance, from a cursory search.
Cheers,
Kevin
On Wed, Feb 20, 2013 at 8:42 AM, Andrew Grieve wrote:
> Would definitely be better to
Just tried the tests and they are all passing for me (on simulator)
On Wed, Feb 20, 2013 at 11:38 AM, Becky Gibson wrote:
> This morning I did git pull apache next for mobile-spec and got this:
> Updating 3e3d075..842e603
> Fast-forward
> VERSION | 2 +-
> autote
Cool will do (shortly). I've also added benches for:
- reading a file within the www/ folder via XHR
- reading a file from the PERSISTENT filesystem via File API
- reading a file from the TEMPORARY filesystem via File API
I'll take a look at adding this info into ci.cordova.io today.
On 2/20/13
Would definitely be better to expose that property as a protocol. That's
the whole point of having the protocol in the first place :P.
I forget if I created a bug for it yet, but cutting down on the number of
public symbols is definitely a TODO for both iOS and Android codebases.
On Wed, Feb 20,
This morning I did git pull apache next for mobile-spec and got this:
Updating 3e3d075..842e603
Fast-forward
VERSION | 2 +-
autotest/tests/file.tests.js | 14 ++
autotest/tests/filetransfer.tests.js | 27 +--
cordova.js
Relevant bug for this discussion is here:
https://issues.apache.org/jira/browse/CB-285
I've written / read files to this location using the "File Explorer" view
built into Eclipse's ADT.
On Tue, Feb 19, 2013 at 7:10 PM, Jesse wrote:
> seems to me, temp should be whatever is returned by getCach
It's not a bug-fix, so push to master :)
On Tue, Feb 19, 2013 at 4:50 PM, Filip Maj wrote:
> K I've got a little bit ready. Just benches:
>
> 1. The # of exec invocations possible in a time interval
> 2. The # of exec callback invocations possible in a time interval
>
> Now my conundrum is: whe
That was my suspicion but i have no data on this yet. Which
mob-spec version? I can verify.
On Wednesday, February 20, 2013, Becky Gibson wrote:
> Just an FYI - I ran mobile-spec yesterday (using an older version) and I
> only had one failure so maybe the issue is with the tests themselves.
>
>
>
Just an FYI - I ran mobile-spec yesterday (using an older version) and I
only had one failure so maybe the issue is with the tests themselves.
On Wed, Feb 20, 2013 at 11:11 AM, Shazron wrote:
> On iOS just touch and hold, drag then copy :)
>
> On Wednesday, February 20, 2013, Michal Mocny wrote
Not beyond the twitch, no. :) The current de facto implementation works for
our uses. The latter (header) issue was honestly the first time I'd
noticed, doing a code review where "#import CDVCommandDelegateImpl.h" was
being added to my view controller's .m file, and I didn't understand why.
I can
On iOS just touch and hold, drag then copy :)
On Wednesday, February 20, 2013, Michal Mocny wrote:
> Shaz how did you generate that text file output? Did you open remote
> inspector and copy console output manually?
>
>
> On Wed, Feb 20, 2013 at 3:33 AM, Shazron >
> wrote:
>
> > Tried mob-spec o
Shaz how did you generate that text file output? Did you open remote
inspector and copy console output manually?
On Wed, Feb 20, 2013 at 3:33 AM, Shazron wrote:
> Tried mob-spec on an iPhone 3GS running 6.0.1 (to rule out any errors due
> to the new 6.1.2 update) - same number of errors as the
Thanks for mentioning this. Would you like to file that bug and/or submit
a pull request?
Also, do you have some motivating reason for moving to a "more
protocol-based property"? I understand your twitch, but am curious if you
are trying to replace with another implementation?
-Michal
On Tue,
Tried mob-spec on an iPhone 3GS running 6.0.1 (to rule out any errors due
to the new 6.1.2 update) - same number of errors as the previous two
devices.
On Wed, Feb 20, 2013 at 12:23 AM, Shazron wrote:
> I tagged iOS 2.5.0rc1 but there are 22 mobile-spec failures (21 related to
> filetransfer).
I tagged iOS 2.5.0rc1 but there are 22 mobile-spec failures (21 related to
filetransfer). I'll examine them tomorrow and fix for a re-tag. The
mobile-spec failures are attached as a text file. Tested on an iPhone 5
with iOS 6.1.2 and iPhone 4 with iOS 5.1.1, exact same failures.
On Tue, Feb 19, 2
78 matches
Mail list logo
