What are you guys talking about, we only have 21 currently, doubling it
won't matter ;)
https://git-wip-us.apache.org/repos/asf?s=cordova
Anis -- I expect Linus Torvalds to chime in on this thread any day now ;)
On Fri, Feb 8, 2013 at 10:39 AM, Anis KADRI wrote:
> I hate to say this but I thin
> First pass: a test/ directory with one or more \w+.test.js files? Tools
> can find the .test.js files and run them automagically?
Yes.
> Up to the author to decide which test framework to run with (jasmine,
> their own, qunit, whatever). All necessary supporting files to be included
> under ./t
First pass: a test/ directory with one or more \w+.test.js files? Tools
can find the .test.js files and run them automagically?
Up to the author to decide which test framework to run with (jasmine,
their own, qunit, whatever). All necessary supporting files to be included
under ./test as well?
Wh
I hate to say this but I think this is where Subversion is better than Git.
One can checkout a sub-folder and does not need multiple repositories :-)
On Fri, Feb 8, 2013 at 7:33 AM, Michal Mocny wrote:
> [image: Inline image 1]
>
>
> On Fri, Feb 8, 2013 at 10:10 AM, Brian LeRoux wrote:
>
>> Fo
[image: Inline image 1]
On Fri, Feb 8, 2013 at 10:10 AM, Brian LeRoux wrote:
> For Git repos, I think so.
>
> On Fri, Feb 8, 2013 at 6:53 AM, Marcel Kinard wrote:
> > Have we set a record for the number of repositories for a single project
> at Apache? ;-)
> >
> > On Feb 8, 2013, at 2:40 AM, B
For Git repos, I think so.
On Fri, Feb 8, 2013 at 6:53 AM, Marcel Kinard wrote:
> Have we set a record for the number of repositories for a single project at
> Apache? ;-)
>
> On Feb 8, 2013, at 2:40 AM, Brian LeRoux wrote:
>
>> Thanks for driving this Andrew! I hope infra doesn't hate us for t
Have we set a record for the number of repositories for a single project at
Apache? ;-)
On Feb 8, 2013, at 2:40 AM, Brian LeRoux wrote:
> Thanks for driving this Andrew! I hope infra doesn't hate us for this!!
>
> On Thu, Feb 7, 2013 at 7:44 AM, Andrew Grieve wrote:
>> https://issues.apache.o
Thanks for driving this Andrew! I hope infra doesn't hate us for this!!
On Thu, Feb 7, 2013 at 7:44 AM, Andrew Grieve wrote:
> https://issues.apache.org/jira/browse/INFRA-5839
>
>
> On Thu, Feb 7, 2013 at 10:36 AM, Andrew Grieve wrote:
>
>> Yep, agree. Until we can actually come up with somethin
Yes, each plugin should be responsible for its own tests. This is something
that we should practice with the core plugins and encourage with
third-party plugins.
I'm still playing catch up, but this is something that must be added to the
plugin spec IMO.
Michael
On Thu, Feb 7, 2013 at 12:48 PM,
This is definitely what I had envisioned as well..
On 2/7/13 11:13 AM, "Andrew Grieve" wrote:
>If someone wants to lead the charge on this angle of the plugin
>splitting-out, that would be awesome. On the priority list though, I think
>it's pretty low. Right now you have to set up the project f
If someone wants to lead the charge on this angle of the plugin
splitting-out, that would be awesome. On the priority list though, I think
it's pretty low. Right now you have to set up the project file, add the
JS, and then run the tests. This model will still work when plugins are
separated out.
I don't want to jump forward too far, but would it make sense to breakup
mobile-spec in a similar way so that the tests for a plugin are actually
located in the plugin's repo? Then the test and the function under test would
be synchronized. And it could potentially open the way for third-parties
https://issues.apache.org/jira/browse/INFRA-5839
On Thu, Feb 7, 2013 at 10:36 AM, Andrew Grieve wrote:
> Yep, agree. Until we can actually come up with something better, we need
> to support Media.
>
>
> On Wed, Feb 6, 2013 at 3:13 PM, Becky Gibson wrote:
>
>> Well, we still need an API/plugin
Yep, agree. Until we can actually come up with something better, we need to
support Media.
On Wed, Feb 6, 2013 at 3:13 PM, Becky Gibson wrote:
> Well, we still need an API/plugin for playing audio. The w3c spec is
> pretty involved. In the past Simon has suggested we try to unify around
> HT
Well, we still need an API/plugin for playing audio. The w3c spec is pretty
involved. In the past Simon has suggested we try to unify around HTML audio.
At any rate I don't think we can just get rid of it.
Sent from my iPhone
On Feb 6, 2013, at 2:52 PM, Andrew Grieve wrote:
> +1
>
>
> O
+1
On Wed, Feb 6, 2013 at 2:41 PM, Brian LeRoux wrote:
> So instead of revisiting it just let it die and kick up a new one for web
> audio?
>
> On Wed, Feb 6, 2013 at 11:23 AM, Andrew Grieve
> wrote:
> > So... back to cordova-plugin-media then?
> >
> >
> > On Wed, Feb 6, 2013 at 1:59 PM, Brian
So instead of revisiting it just let it die and kick up a new one for web audio?
On Wed, Feb 6, 2013 at 11:23 AM, Andrew Grieve wrote:
> So... back to cordova-plugin-media then?
>
>
> On Wed, Feb 6, 2013 at 1:59 PM, Brian LeRoux wrote:
>
>> exactly! And plugins, I think, will end up being indepe
So... back to cordova-plugin-media then?
On Wed, Feb 6, 2013 at 1:59 PM, Brian LeRoux wrote:
> exactly! And plugins, I think, will end up being independently
> versioned so if ppl want old and busted they can have it. =P
>
> On Wed, Feb 6, 2013 at 10:48 AM, Andrew Grieve
> wrote:
> > SGTM. Fir
exactly! And plugins, I think, will end up being independently
versioned so if ppl want old and busted they can have it. =P
On Wed, Feb 6, 2013 at 10:48 AM, Andrew Grieve wrote:
> SGTM. First step towards deprecation is turning it into a plugin so that
> people can not install it :)
>
>
> On Wed,
SGTM. First step towards deprecation is turning it into a plugin so that
people can not install it :)
On Wed, Feb 6, 2013 at 1:41 PM, Brian LeRoux wrote:
> I was thinkin we'd just deprecate the media spec altogether for a
> starter/subset of the web audio api (perhaps polyfil the audio element
I was thinkin we'd just deprecate the media spec altogether for a
starter/subset of the web audio api (perhaps polyfil the audio element
while we're at it).
should we kick up a thread about that?
(Added file transfer to the non-spec plugins.)
On Wed, Feb 6, 2013 at 10:22 AM, Filip Maj wro
Totally makes sense to separate them.
File is spec-based, FileTransfer is not.
On 2/6/13 10:16 AM, "Andrew Grieve" wrote:
>I thought FileTransfer was a part of File. Maybe it makes sense to
>separate
>them though?
>
>
>On Wed, Feb 6, 2013 at 12:00 PM, Becky Gibson
>wrote:
>
>> Yes, I shouldn't
I thought FileTransfer was a part of File. Maybe it makes sense to separate
them though?
On Wed, Feb 6, 2013 at 12:00 PM, Becky Gibson wrote:
> Yes, I shouldn't have confused the issue about audio and media! I guess I
> just get annoyed when I go to mobile spec and it is labelled as "audio" :-)
Yes, I shouldn't have confused the issue about audio and media! I guess I
just get annoyed when I go to mobile spec and it is labelled as "audio" :-)
We can leave it as cordova-plugin-media so it matches the JS api name.
Although, I think we are creating the same type of confusion if we rename
c
Great! I like the spec-based names. I think I have the opposite thought as
Becky. Our current media plugin doesn't follow the WebAudio spec at all.
How about we call it cordova-media for now since that's what it's called in
our docs, and then if we ever implement WebAudio, then we'll have the name
Just kicked up a quick wiki page to help vett this. I'm thinking we
try to stay as close to the spec names as possible.
http://wiki.apache.org/cordova/Core%20Plugin%20Name%20Proposal
On Tue, Feb 5, 2013 at 11:40 AM, Becky Gibson wrote:
> My only comment would be about media. Currently it just
My only comment would be about media. Currently it just supports audio so
perhaps codova-plugin-audio makes more sense and we can leave media open
for the rewrite. Although, I do realize the api is labelled "media" so
perhaps it would be too confusing to change the repo name. Just a
thought.
Before I go ahead with this, let's agree upon the repo names / which
plugins to include.
Here's the proposed list:
Repos to create:
cordova-plugin-accelerometer
cordova-plugin-battery
cordova-plugin-camera
cordova-plugin-capture
cordova-plugin-compass
cordova-plugin-contacts
cordova-plugin-devic
Great! Sounds like an agreement :). I'll file an INFRA to get them created.
On Mon, Feb 4, 2013 at 9:44 PM, Shazron wrote:
> +1 on separate repos. It's the sane choice.
>
>
> On Mon, Feb 4, 2013 at 11:53 PM, Jesse wrote:
>
> > +1, I agree on the separate repositories.
> > I still contend that
+1 on separate repos. It's the sane choice.
On Mon, Feb 4, 2013 at 11:53 PM, Jesse wrote:
> +1, I agree on the separate repositories.
> I still contend that nothing should need to be 'built' and there should be
> NO dependencies on the plugins from cordova-js, ( aside from device.js +
> network
+1, I agree on the separate repositories.
I still contend that nothing should need to be 'built' and there should be
NO dependencies on the plugins from cordova-js, ( aside from device.js +
network.js which are both required pre device ready, and I think should
remain in the cordova-js repo )
On
+1 for separate repositories. Should take a bit longer than normal to
package a release but not too long especially if the repos are pulled from
a local source (ie no network overhead).
I'd be ok to ship a set of default plugins and give the ability for people
to build their 'own' Cordova.
On Mon
I'm in favor of discreet plugin repos. It shouldn't effect a release
if we automate install/remove and add to the Coho tool... though
perhaps this is a naive assumption.
On Mon, Feb 4, 2013 at 1:44 PM, Andrew Grieve wrote:
> Thought it'd be worth having a discussion around whether we want a separ
33 matches
Mail list logo
