+1 to negligence, or might it be ignorance?
The attic sounds like its where you put code you're ashamed of.
Cheers,
Jesse
Sent from my iPhone5.5
On 2013-03-21, at 3:41 PM, Brian LeRoux wrote:
Attic seems like more work than outright neglect. Might be for
conceptual purity we want to move Bad
Hi all,
We have an android application mixing native views and a CordovaWebView.
The problem is the CordovaWebView request the focus when launching the
application even in our case it should not be the view selected by
default. Unfortunately there is no easy way to override this behavior
becaus
I knew you'd bring that up! We'll talk more tmrw.
On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI wrote:
> …or you can have functions do discrete actions like so:
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=bin/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518
…or you can have functions do discrete actions like so:
https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=bin/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6;hb=HEAD
…instead of creating more inodes.
On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote:
> You could make more scripts as helper scripts, but I still think that it
> will be confusing if a user types "ls" and sees a large number of scripts,
> having to guess what each of them does.
Put them in a subdir called ./lib and be done w/ it.
> I don't think having more scripts will make it
On Thu, Mar 21, 2013 at 6:51 PM, Filip Maj wrote:
> It looks like we are split between Reductionist (four commands and/or less
> commands) and.. The opposite.. Of reductionists? Antireductionist?
>
> Two points I think supporting the antireductionist argument:
>
> 1. number of scripts being an is
Who's four-command proposal is it? Anis' or Andrew's?
On 3/21/13 3:14 PM, "Brian LeRoux" wrote:
>I think we can have our cake and eat it too. We should have four high
>level commands. Those commands can shell to lower level discreetly
>testable commands. The end user will never know the differen
Yes... Why Not... That's part of the fun ... Isn't it?? [?]
On Thu, Mar 21, 2013 at 6:14 PM, Brian LeRoux wrote:
> I think we can have our cake and eat it too. We should have four high
> level commands. Those commands can shell to lower level discreetly
> testable commands. The end user will nev
It looks like we are split between Reductionist (four commands and/or less
commands) and.. The opposite.. Of reductionists? Antireductionist?
Two points I think supporting the antireductionist argument:
1. number of scripts being an issue because of possible bug repetition
across scripts is put t
+1
On 22/03/2013, at 9:14 AM, Brian LeRoux wrote:
> I think we can have our cake and eat it too. We should have four high
> level commands. Those commands can shell to lower level discreetly
> testable commands. The end user will never know the difference. The
> developers win the tight abstrac
My hero.
On 22/03/2013, at 8:36 AM, Shazron wrote:
> Yup :)
>
>
> On Thu, Mar 21, 2013 at 2:20 PM, Tommy-Carlos Williams
> wrote:
>
>> Shazron,
>>
>> So do your FileTransfer tests resolve CB-2687 [1] ?
>>
>> [1] https://issues.apache.org/jira/browse/CB-2687
>>
>>
>> On 22/03/2013, at 3:2
Attic seems like more work than outright neglect. Might be for
conceptual purity we want to move Bada there but I could see Qt and
webOS rising from their slumber.
On Thu, Mar 21, 2013 at 3:30 PM, Anis KADRI wrote:
> and no apache attic [1] ?
>
> [1] http://attic.apache.org/
>
>
> On Thu, Mar 21
and no apache attic [1] ?
[1] http://attic.apache.org/
On Thu, Mar 21, 2013 at 3:28 PM, Brian LeRoux wrote:
> This means we're going to leave Bada, Qt, webOS at their latest tags,
> and not dist. (Code still accessible, etc.)
>
> We'll continue as normal for BB, for now.
>
>
>
> On Thu, Mar 21
This means we're going to leave Bada, Qt, webOS at their latest tags,
and not dist. (Code still accessible, etc.)
We'll continue as normal for BB, for now.
On Thu, Mar 21, 2013 at 3:09 PM, Gord Tanner wrote:
> I am confused, who are the stewards and what platforms are being stewarded?
>
> Sent
I'll be likely doing it from home. Some of the other committers too. It's
open to the public, essentially, so setting a limit of 10 I think is
unreasonable.
On 3/21/13 3:18 PM, "Braden Shepherdson" wrote:
>I think it's 10. Will we have that many different rooms/laptops? All the
>Googlers will be
http://my.adobeconnect.com/cordova
I'll aim to start around 905am. Connect supports like 300 people. You'll
need flash (sorry) and probably have to use firefox (sorry).
On 3/21/13 3:09 PM, "Filip Maj" wrote:
>I am looking into setting up a connect room as hangouts only support 20
>people I beli
I think it's 10. Will we have that many different rooms/laptops? All the
Googlers will be in one room, hopefully most of the Apache SF folks can do
the same.
On Thu, Mar 21, 2013 at 6:09 PM, Filip Maj wrote:
> I am looking into setting up a connect room as hangouts only support 20
> people I be
I think we can have our cake and eat it too. We should have four high
level commands. Those commands can shell to lower level discreetly
testable commands. The end user will never know the difference. The
developers win the tight abstraction we seek.
Make sense?
On Thu, Mar 21, 2013 at 2:55 PM, A
I am looking into setting up a connect room as hangouts only support 20
people I believe (unless I'm wrong)
Will be posting meeting details shortly
I am confused, who are the stewards and what platforms are being stewarded?
Sent from my iPhone
On 2013-03-21, at 6:00 PM, Filip Maj wrote:
> +1
>
> On 3/21/13 2:12 PM, "Shazron" wrote:
>
>> +1
>>
>>
>> On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny wrote:
>>
>>> +1
>>>
>>>
>>> On Thu,
+1
On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote:
> Ok, I think we have agreement that we'll put these guys on hold until
> they find a steward. This means:
>
> - we won't be taggin them further
> - we won't be including them in a release
>
> This does not mean:
>
> - deletion or archivin
+1
On 3/21/13 2:12 PM, "Shazron" wrote:
>+1
>
>
>On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny wrote:
>
>> +1
>>
>>
>> On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote:
>>
>> > Ok, I think we have agreement that we'll put these guys on hold until
>> > they find a steward. This means:
>> >
>
+1
On Thu, Mar 21, 2013 at 5:32 PM, Michael Brooks wrote:
> +1
>
> On Thu, Mar 21, 2013 at 2:12 PM, Shazron wrote:
>
> > +1
> >
> >
> > On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny
> wrote:
> >
> > > +1
> > >
> > >
> > > On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote:
> > >
> > > > Ok,
On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks wrote:
> +1 Fil's outlined design.
>
> I'm still not convinced of what Anis and Andrew are in favour of. Having
> each script do more will make it more difficult for common results across
> all platforms.
>
> I really like Anis's suggestion of just f
Yup :)
On Thu, Mar 21, 2013 at 2:20 PM, Tommy-Carlos Williams
wrote:
> Shazron,
>
> So do your FileTransfer tests resolve CB-2687 [1] ?
>
> [1] https://issues.apache.org/jira/browse/CB-2687
>
>
> On 22/03/2013, at 3:22 AM, Shazron wrote:
>
> > Thanks Andrew!
> > I've got new mobile-spec FileTra
+1
On Thu, Mar 21, 2013 at 2:12 PM, Shazron wrote:
> +1
>
>
> On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny wrote:
>
> > +1
> >
> >
> > On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote:
> >
> > > Ok, I think we have agreement that we'll put these guys on hold until
> > > they find a steward
+1 Fil's outlined design.
I'm still not convinced of what Anis and Andrew are in favour of. Having
each script do more will make it more difficult for common results across
all platforms.
I really like Anis's suggestion of just four scripts. What's the motivation
> for having many scripts? Having
Shazron,
So do your FileTransfer tests resolve CB-2687 [1] ?
[1] https://issues.apache.org/jira/browse/CB-2687
On 22/03/2013, at 3:22 AM, Shazron wrote:
> Thanks Andrew!
> I've got new mobile-spec FileTransfer tests in for the new basic auth
> upload/download plus the corresponding new deploy
+1
On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny wrote:
> +1
>
>
> On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote:
>
> > Ok, I think we have agreement that we'll put these guys on hold until
> > they find a steward. This means:
> >
> > - we won't be taggin them further
> > - we won't be i
+1
On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote:
> Ok, I think we have agreement that we'll put these guys on hold until
> they find a steward. This means:
>
> - we won't be taggin them further
> - we won't be including them in a release
>
> This does not mean:
>
> - deletion or archivin
Ok, I think we have agreement that we'll put these guys on hold until
they find a steward. This means:
- we won't be taggin them further
- we won't be including them in a release
This does not mean:
- deletion or archiving or attic for the src
(Think of it as a pause button!)
Agree/disagree?
Ya tend to agree w/ the workflows you describe Jesse. Not at the
exlusion of discreet scripts however. We probably should have small
focused scripts and then compose the workflow scripts from them.
(Making it easier to test and compose new scripts and tooling.)
On Thu, Mar 21, 2013 at 12:07 AM,
While I respect the benefits I really doubt we can get rid of eval and
inline scripts ever. Thats the nature of the web.
Subsequent efforts that forget this facet of the web and pretend to
fix the issue have thus far tended to fail. In any case, we are unable
to fix this issue unless we start ship
I think your prioritization is correct. It would be great to ship w/
our docs but no rush.
On Thu, Mar 21, 2013 at 11:36 AM, Braden Shepherdson
wrote:
> Yes, that's on my list of things to do. I'm making progress along that
> list, but it's currently outrunning me.
>
> Do people like the idea of
Originally I thought it would be great to get it into the
docs.cordova.iodocs, but then the audience is pretty small
(committers) - in my opinion
the wiki would be better for that.
My 2 cents is the ContributorWorkflow (
http://wiki.apache.org/cordova/ContributorWorkflow) would be a better
candida
https://docs.google.com/document/d/1jcXrmmXR1dL3VsMymSxMYabDYvjgweZHX5dPmfizbgo/edit?usp=sharing
The Google team spent over an hour debating various issues around this and
packaging, and we've got some arguments, counterarguments, and proposed
solutions in this doc. It's intended as a primer for i
Yes, that's on my list of things to do. I'm making progress along that
list, but it's currently outrunning me.
Do people like the idea of putting this doc into the docs.cordova.io docs?
Or do we prefer to keep contributor-related things in the wiki? If the
latter, it can wait, but if the former th
Braden also published this detailed guide for contributors on the topic:
https://googledrive.com/host/0B8sLcyOAEX-XUHAxNXhISE5rTTg/guide_contributing_index.md.html
(Which I'm guessing will make its way into our docs proper?)
On Thu, Mar 21, 2013 at 10:09 AM, Filip Maj wrote:
> Alright folks, m
Alright folks, mobile-spec and cordova-js are tagged 2.6.0rc1, and the
2.6.x branches on both those repos are now pushed up. Gogo release mode!
On 3/21/13 9:12 AM, "James Jong" wrote:
>Nice. Thanks Michal.
>
>-James Jong
>
>On Mar 21, 2013, at 11:57 AM, Michal Mocny wrote:
>
>> Yes, the intent
Thanks for the summary Braden!
On 3/21/13 7:36 AM, "Braden Shepherdson" wrote:
>I meant to send an email about this last night. Here's the (high-level)
>process we'll need to follow for each of the repos.
>
>Step 0: This time only, delete the 'next' branch. We're not using them
>anymore, and the
Sweet, I will kick off the tagging issues
On 3/21/13 9:22 AM, "Shazron" wrote:
>Thanks Andrew!
>I've got new mobile-spec FileTransfer tests in for the new basic auth
>upload/download plus the corresponding new deployed
>cordova-filetransfer.jitsu.com script. There might be failures on some
>plat
Thanks Andrew!
I've got new mobile-spec FileTransfer tests in for the new basic auth
upload/download plus the corresponding new deployed
cordova-filetransfer.jitsu.com script. There might be failures on some
platforms for these 2 new tests (WP7 comes to mind since it doesn't support
window.btoa in
Nice. Thanks Michal.
-James Jong
On Mar 21, 2013, at 11:57 AM, Michal Mocny wrote:
> Yes, the intent is to have living branches. We may also cherry-pick
> regressions back to more than just the current release.
>
>
> On Thu, Mar 21, 2013 at 11:50 AM, James Jong wrote:
>
>> Thanks Braden.
Yes, the intent is to have living branches. We may also cherry-pick
regressions back to more than just the current release.
On Thu, Mar 21, 2013 at 11:50 AM, James Jong wrote:
> Thanks Braden. Is the intent to have 'living' branches for each major
> release (e.g. 2.6, 3.0) which contain tags
Thanks Braden. Is the intent to have 'living' branches for each major release
(e.g. 2.6, 3.0) which contain tags for release candidates and minor revisions?
So going forward we would have 2.6.x , 3.0.x, ... branches?
-James Jong
On Mar 21, 2013, at 10:36 AM, Braden Shepherdson wrote:
> I me
I meant to send an email about this last night. Here's the (high-level)
process we'll need to follow for each of the repos.
Step 0: This time only, delete the 'next' branch. We're not using them
anymore, and they'll just add confusion.
Step 1: Checkout and pull master.
Step 2: git checkout -b 2.6.
Is the new release branching process for 2.6 posted somewhere? I didn't see it
searching through the emails.
-James Jong
On Mar 20, 2013, at 1:37 PM, Braden Shepherdson wrote:
> My changes are in.
>
>
> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote:
>
>> Alright sounds like we need to
> Noticed a cordova-js pull request for Windows
If you are referring to "Windows build (CB-1667 and CB-2588)" [1], I'd
like to clarify that it is about Windows as a development platform
[2][3], not as a cordova platform
[1] https://github.com/apache/cordova-js/pull/14
[2] https://issues.apache.or
renaming stuff is easy.
Does it make sense to log without running? or does log also launch? where?
Sounds to me like logging is an option attached to a run command.
What is the point of cleaning if you're not going to build right after?
trying to free up hard drive space? anal much? or is clean ju
49 matches
Mail list logo
