Hi James, I will be at WWDC next week, let's meet up. Feel free to drop by
the Adobe SF office as well :)
(although its not exactly near Moscone West)
On Wed, Jun 5, 2013 at 8:42 AM, James Jong wrote:
> I was able to get a late ticket to go to WWDC so I'll be in SF next week.
> Anyone else her
The reverts were only on the 2.8.0 branch, not on master. It's
currently totally broken right now.
On Wed, Jun 5, 2013 at 8:09 PM, Michal Mocny wrote:
> 100 yard summary: our intern Shravan from last term was adding this as part
> of his app-harness work. This specific change landed a too hasti
100 yard summary: our intern Shravan from last term was adding this as part
of his app-harness work. This specific change landed a too hastily as
there were some issues in corner cases (perhaps over-eagerness due to time
pressure as he approach term end), but all actual uses of DataResource
should
Since I'm starting as a contributor and not a committer I was talking from
that perpective, to follow the process that is in place for contributors to
submit pull requests to be review and committed by committers.
--Carlos
On Wed, Jun 5, 2013 at 8:28 PM, Jesse wrote:
> Personally, if I had
Personally, if I had a change that I wanted to add to Android, or iOS, I
would send a pull request to Joe, or Shazron respectively. I effectively
consider them to be the gatekeepers for their respective platforms as they
work on them every day and I consider them to have a much deeper knowledge
of
The thing is that people don't start out as committers. It has to be earned
over time. Committership is with an individual, not a company.
On Jun 5, 2013 4:32 PM, "Filip Maj" wrote:
> Agree with Lorin, if you are a committer, go ahead and push your changes
> but please for the love of god test e
Agree with Lorin, if you are a committer, go ahead and push your changes
but please for the love of god test every change you make. If you cannot
test due to lack of devices, then please for the love of god ask someone
on the list to do the testing for you.
On 6/5/13 4:30 PM, "Lorin Beer" wrote:
-1 for allowing time for discussion/code-review between diff/commit/pull
request to the issue and committing to master, if I understand the
suggestion.
For non-committer contributors, yes, this is a natural workflow and
a necessary step for getting your code into the project in the first place.
B
I like the idea of keeping 2.x around and updating it to fix any bugs filed
for 2.x
As for when to break out the plugins and merge/rebase the 3.0 branch, this
should wait until after 2.9.x is released. Otherwise the users would need
node/plugman in order to create a project, and this is a dependen
Hey
Why is DataResouce still in master? I don't want this code to go into
2.9.0 or 3.0.0, since I have no idea what this is trying to
accomplish. I'm going to start ripping it out of master tomorrow if
someone doesn't tell me why it should still be here.
Seriously, WTF?
There's merits to both and I'm open to either approach. To summarize:
- dump the 3.0 branch into master now, and expand the ./create scripts so
that they call into plugman to re-add the core apis. Pro: gives us more
time to bake the frameworks with plugins ripped out. Con: probably not
ready right
+1.
However, do we want to support 2.x for some extended time during the
tooling transition to 3.x for everyone? One way to do this is just land a
constant stream of point releases on the 2.9.x branch. Another way could
be to branch a 2.x long-lived feature branch before merging in 3.0.0 and
con
Adding to Bradens answer, here are some things I remember discussing:
- Chrome/Android teams have significantly harder constraints than cordova
would have in terms of backwards compatibility, stability, and API
consistency. Cordova could probably do interesting things if we didn't
need to support
Ya our experiments at Adobe yielded apps around 17mb. (Still beefy for
Hello World!) Also finding that having a 4+ as a req appears to not be
a big deal to the dev community.
On Wed, Jun 5, 2013 at 1:55 PM, Braden Shepherdson wrote:
> This is a thing. Unfortunately the person most connected to t
The last time we tested this approach, it was 16 MB, not 30 MB and
many apps are upwards of that now anyway. I don't think 30 MB is a
barrier if your app doesn't suck.
Also, who got stuck being substitute Andrew? I need someone other
than me to tag Android for 2.9.0, since I'll be on vacation th
This is a thing. Unfortunately the person most connected to the state of
Chrome WebViews is Andrew, who is out with a strong case of newborn baby
for a few weeks. We (the Google Cordova team) are chasing some tangential
deadlines at the moment and not really ready to set up a buildbot.
I think the
+1 on moving to Status:"In Progress" to denote someone is working on it
+1 on allowing time for discussion/code-review between request and commit
Sorry trying to learn the Cordova lingo :-)
--Carlos
On Wed, Jun 5, 2013 at 2:32 PM, Jeffrey Heifetz wrote:
> I also think there's value in having s
+1
Lets do that nao.
On Wed, Jun 5, 2013 at 12:11 PM, Filip Maj wrote:
> Joe and I were just talking about how the process of integrating an
> API-less cordova (I.e. The 3.0 branches) back into the master branches
> would work. I imagine that, as soon as we create a release branch for
> 2.9.0 /
So this is a thing:
https://github.com/pwnall/chromeview
And we know our friends at The Google are going to give us an embedded
ChromeView (someday maybe).
So is this something the Cordova team should be considering?
Can we work w/ our committers from Chromium to create a buildbot that
creates
I also think there's value in having some time between posting a
diff/commit/pull request to the issue and committing to master to allow
some discussion.
On 13-06-05 2:25 PM, "Lorin Beer" wrote:
>Yes, putting a comment on the issue itself should be sufficient. If
>you're familiar with the person
Agreed. When the 3.0 branches were created, I said "they should have been
called 'future' or similar", since that's what they really are. The 3.0
branch that we've been working on so far is not the 3.0.x release branch.
Braden
On Wed, Jun 5, 2013 at 1:41 PM, Ian Clelland wrote:
> That makes se
Yes, putting a comment on the issue itself should be sufficient. If
you're familiar with the person, im/irc message is appreciated, but
not necessary.
Generally, Fil is correct. I generally do not mark issues I'm working
on as "in progress", but that's something I will immediately adress.
On Wed,
That makes sense. That is probably the only reason to ever merge such a
branch back into master -- essentially the 3.0.0 branch that we have now is
treated as a 'feature' branch, to be merged into master when it is ready
(and after the long-lived 2.9.x branch splits off).
Then, later, we can actua
Joe and I were just talking about how the process of integrating an
API-less cordova (I.e. The 3.0 branches) back into the master branches
would work. I imagine that, as soon as we create a release branch for
2.9.0 / tag 2.9.0rc1, we will merge/rebase the 3.0 branch into master
right away. Then we
A lot of work is being put into breaking out the plugins into individual
repositories, as a prep for 3.0. One of my goals on this project is to
ship a Cordova for 3.0 that allows users to compose a cordova application
shell with whatever plugins they wish, including the core APIs. This way
users do
Pretty much.
My assumption is when looking through JIRA that if an issue isn't "In
Progress" then I can freely assign to myself and mark it as "In Progress"
to denote that I am working on it.
On 6/5/13 9:28 AM, "Carlos Santana" wrote:
>Lorin,
> When you say "ping the person it is assigned to"
Lorin,
When you say "ping the person it is assigned to" you mean put a comment
on the JIRA ticket?
This way everyone is aware that someone is interested on taking over the
ticket or have some input?
Sorry if it was a dumb, question I'm trying to understand the workflow of
contributing
(open tic
I was able to get a late ticket to go to WWDC so I'll be in SF next week.
Anyone else here going and want to meet up? Perhaps we can get together one
evening? All those around welcome, not limited to those going to WWDC.
-James Jong
I have chalked up adding "run" which will directly translate into a call
to the platform scripts [1].
Mike, note that cordova-cli uses "compile" AND "build" - build does a
"prepare" before it compiles, whereas compile simply, well, compiles.
[1] https://issues.apache.org/jira/browse/CB-3612
On 6
Just pushed a fix. Try 2.8.4 from npm, and use either the "-d" or
"--verbose" flags.
On 6/5/13 8:14 AM, "Brian LeRoux" wrote:
>No worries John, I think we can all agree better and more verbosity
>(opting into it) is useful for polishing this gem into a two handed
>bastard sword that kills mobile
Good timing John as I am *just* about to commit a fix for CB-2452 :)
On 6/5/13 8:05 AM, "Wargo, John" wrote:
>Of course, after I sent that email, I noticed that something was already
>posted to Jira (CB-2452) about this, sorry.
>
>-Original Message-
>From: John Wargo [mailto:jwarg...@gma
No worries John, I think we can all agree better and more verbosity
(opting into it) is useful for polishing this gem into a two handed
bastard sword that kills mobile dragons.
On Wed, Jun 5, 2013 at 11:05 AM, Wargo, John wrote:
> Of course, after I sent that email, I noticed that something was a
Of course, after I sent that email, I noticed that something was already posted
to Jira (CB-2452) about this, sorry.
-Original Message-
From: John Wargo [mailto:jwarg...@gmail.com]
Sent: Wednesday, June 05, 2013 8:58 AM
To: Cordova Dev
Subject: CLI output
When the CLI kicks out errors,
+1 for stack traces. I actually did this in plugman while debugging
something, I forget if it was removed in time for release. Not a big deal
if not.
Braden
On Wed, Jun 5, 2013 at 8:58 AM, John Wargo wrote:
> When the CLI kicks out errors, I wonder if developers would benefit from
> some addit
Welcome Carlos!
On 6/4/2013 3:01 PM, Carlos Santana wrote:
Hi I'm currently blessed to recently join a team (Marcel, James, Mike,
Lisa) here at IBM dedicated to Apache Cordova.
I have being using PhoneGap/Cordova for the last 3 years as a consumer
working on an App for IBM (http://ibm.co/SVP7LK
I agree - makes sense.
On 6/4/2013 12:41 PM, Michael Brooks wrote:
I'm in favour of using "build," "run," and "install" because these commands
match the platform-scripts. They are also arguably more descriptive of
their resulting action.
Currently, the PhoneGap CLI also uses "build," "run," and
When the CLI kicks out errors, I wonder if developers would benefit from some
additional information being spit out with the error. I'm thinking that my
recent toubleshooting efforts would benefit from it spitting out the CLI
version, Node version, and the CLI file and line number that was bein
37 matches
Mail list logo
