Nightly build #484 for cordova has succeeded!

[Apache Jenkins Server]

Nightly build #484 for cordova has succeeded!
The latest nightly has been published and you can try it out with 'npm i -g 
cordova@nightly'

For details check build console at 
https://builds.apache.org/job/cordova-nightly/484/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-docs pull request #729: Fixed up 'deployment' docs in README.md.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-docs/pull/729


---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[BUILD STATUS] 3 status.cordova.io failures

[Shazron]

Looks like the redirect didn't work since the move to Github Apache Org for
cordova-status, fixed.

3 components have build failures:
1. cordova-paramedic (Travis fail, AppVeyor fail)
2. cordova-fetch (Travis pass, AppVeyor fail)
3. cordova-android (Travis - something wrong with the build badge when
you click on it, AppVeyor fail - but there is a build pending)

Re: [DISCUSS][DOCS] Revert a change

[Dmitry Blotsky]

So, translations were always a semi-manual process. In that sense, they're as 
much an "afterthought" as they ever were. However the current design permits 
automation of translation within its build process pretty cleanly. It's just a 
matter of implementing it. It's not trivial, but it's about as difficult as all 
the other parts of our build process. 

Moreover, it doesn't have to be done before automating deployment. The 
translation step, when implemented, can just be appended to whatever automation 
we choose to have.

In short: we don't need to redesign, we just need to add a translation step to 
the current process.

Kindly,
Dmitry

> On Sep 13, 2017, at 3:32 PM, Filip Maj  wrote:
> 
> To be clear, we don't need to redesign anything to automate docs
> deployment. It is in the realm of possibility to simply automate what
> we have today. I just feel like what we have today is a design where
> translations are an afterthought, which I think is a bad tradeoff,
> especially given the popularity of cordova outside of english-speaking
> countries. _IF_ we were to agree that a redesign is worthwhile, then I
> would recommend we do that first before automating deployment. If the
> PMC deems a redesign of the cordova-docs repo is not important, then
> so be it, and we can automate what we have.
> 
> On Wed, Sep 13, 2017 at 12:09 PM, Dmitry Blotsky
>  wrote:
>> @fil: why is reworking the docs repo needed for automatic deployment?
>> 
>> @steve: could you merge it then? I'm far too rusty on my Cordova-ing to 
>> remember how to set up my remotes to push to the ASF repo, sorry. :(
>> 
>> Kindly,
>> Dmitry
>> 
>>> On Sep 13, 2017, at 1:08 PM, Filip Maj  wrote:
>>> 
>>> We have an issue posted to make docs publishing automatic:
>>> https://issues.apache.org/jira/browse/CB-13162
>>> 
>>> Not to derail the topic, but there is a longer wishlist in that issue,
>>> and I do think achieving the goals in that issue would require
>>> reworking the docs repository quite a bit. We can discuss details in
>>> the issue thread.
>>> 
>>> On Wed, Sep 13, 2017 at 9:47 AM, Dmitry Blotsky
>>>  wrote:
 Yes, ideally our deployment process should be automated. Also, it should 
 *not* be an SVN commit. It should be an rsync or an scp command. I would 
 support any initiatives to move to either one of those. If we had 
 automated deployment, this discussion would be moot.
 
 How much would it cost us to just have a VPS with nginx?
 
 Switching to the topic of deployment docs now. Thanks, Shaz, for bringing 
 this up in discussion. My opinion was that we shouldn't have impactful 
 commands be copy-paste-able, which is why I had the instruction to commit 
 in paragraph text. I think that if a committer doesn't read the full text 
 of the deployment docs, *they should not be deploying*. I can see the 
 argument that if they do read the text but just don't know *how* to commit 
 in SVN, it's annoying to search. However at the top of that section is an 
 explicit link to a quick SVN tutorial. I understand that not everyone 
 reads the fine print, but IMO committers should, and we should explicitly 
 discourage that behaviour.
 
 Ultimately I'm going to defer to Shaz here, but I think it's important to 
 consider the benefits of making deployment *feel* more serious by making 
 RTFD necessary.
 
 Kindly,
 Dmitry
 
> On Sep 13, 2017, at 6:30 AM, Jan Piotrowski  wrote:
> 
> I am actually surprised deploying is a manual process at all.
> Having read the steps, I understand why of course.
> 
> As a person that jumps in on all kinds of projects, I absolutely
> prefer docs that list each and every little step needed (including all
> the `cd` etc).
> 
> The need for manual steps or checks could be emphasized by using a
> numbered list or checklist for the individual steps.
> 
> (Will this stay on SVN even after the repo switch to Github? Merging
> and `gh-pages` is so nice and simple)
> 
> -J
> 
> 2017-09-13 9:02 GMT+02:00 Shazron :
>> This relates solely to instructions on how to *build* the site, and not 
>> the
>> contents of the site itself.
>> 
>> Bringing this up here for discussion since a committer wants to revert a
>> change by another committer, and there is potential for disagreement.
>> 
>> The pull request to revert is here:
>> https://github.com/apache/cordova-docs/pull/729
>> 
>> There has been discussion on the original change here:
>> https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94
>> 
>> Two issues here:
>> 1. The change from `gulp build --prod` to `npm run serve`
>> 2. This instruction here (not reverted in the PR):
>> 

Re: [DISCUSS][DOCS] Revert a change

[Filip Maj]

To be clear, we don't need to redesign anything to automate docs
deployment. It is in the realm of possibility to simply automate what
we have today. I just feel like what we have today is a design where
translations are an afterthought, which I think is a bad tradeoff,
especially given the popularity of cordova outside of english-speaking
countries. _IF_ we were to agree that a redesign is worthwhile, then I
would recommend we do that first before automating deployment. If the
PMC deems a redesign of the cordova-docs repo is not important, then
so be it, and we can automate what we have.

On Wed, Sep 13, 2017 at 12:09 PM, Dmitry Blotsky
 wrote:
> @fil: why is reworking the docs repo needed for automatic deployment?
>
> @steve: could you merge it then? I'm far too rusty on my Cordova-ing to 
> remember how to set up my remotes to push to the ASF repo, sorry. :(
>
> Kindly,
> Dmitry
>
>> On Sep 13, 2017, at 1:08 PM, Filip Maj  wrote:
>>
>> We have an issue posted to make docs publishing automatic:
>> https://issues.apache.org/jira/browse/CB-13162
>>
>> Not to derail the topic, but there is a longer wishlist in that issue,
>> and I do think achieving the goals in that issue would require
>> reworking the docs repository quite a bit. We can discuss details in
>> the issue thread.
>>
>> On Wed, Sep 13, 2017 at 9:47 AM, Dmitry Blotsky
>>  wrote:
>>> Yes, ideally our deployment process should be automated. Also, it should 
>>> *not* be an SVN commit. It should be an rsync or an scp command. I would 
>>> support any initiatives to move to either one of those. If we had automated 
>>> deployment, this discussion would be moot.
>>>
>>> How much would it cost us to just have a VPS with nginx?
>>>
>>> Switching to the topic of deployment docs now. Thanks, Shaz, for bringing 
>>> this up in discussion. My opinion was that we shouldn't have impactful 
>>> commands be copy-paste-able, which is why I had the instruction to commit 
>>> in paragraph text. I think that if a committer doesn't read the full text 
>>> of the deployment docs, *they should not be deploying*. I can see the 
>>> argument that if they do read the text but just don't know *how* to commit 
>>> in SVN, it's annoying to search. However at the top of that section is an 
>>> explicit link to a quick SVN tutorial. I understand that not everyone reads 
>>> the fine print, but IMO committers should, and we should explicitly 
>>> discourage that behaviour.
>>>
>>> Ultimately I'm going to defer to Shaz here, but I think it's important to 
>>> consider the benefits of making deployment *feel* more serious by making 
>>> RTFD necessary.
>>>
>>> Kindly,
>>> Dmitry
>>>
 On Sep 13, 2017, at 6:30 AM, Jan Piotrowski  wrote:

 I am actually surprised deploying is a manual process at all.
 Having read the steps, I understand why of course.

 As a person that jumps in on all kinds of projects, I absolutely
 prefer docs that list each and every little step needed (including all
 the `cd` etc).

 The need for manual steps or checks could be emphasized by using a
 numbered list or checklist for the individual steps.

 (Will this stay on SVN even after the repo switch to Github? Merging
 and `gh-pages` is so nice and simple)

 -J

 2017-09-13 9:02 GMT+02:00 Shazron :
> This relates solely to instructions on how to *build* the site, and not 
> the
> contents of the site itself.
>
> Bringing this up here for discussion since a committer wants to revert a
> change by another committer, and there is potential for disagreement.
>
> The pull request to revert is here:
> https://github.com/apache/cordova-docs/pull/729
>
> There has been discussion on the original change here:
> https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94
>
> Two issues here:
> 1. The change from `gulp build --prod` to `npm run serve`
> 2. This instruction here (not reverted in the PR):
> https://github.com/apache/cordova-docs/commit/d61f3ddc84dac4b013c0607230b9cf10921a416b
>
> Issue (1) has some discussion in the GH link above for the original 
> change.
>
> Issue (2) there was some discussion in the Cordova Slack, that the reason
> the `svn commit` wasn't there in the first place is to prevent copy/paste
> of the commands without going through the changes step by step since
> deploying to a site is an expensive operation that can screw up the site 
> if
> proper care was not done.
>
> My reason for adding the command was that the instructions are not 
> complete
> (when I had to do it myself when updating the docs for cordova-ios
> release). I understand the rationale, but the instructions seem incomplete
> (especially for new committers that haven't heard of 

Re: [DISCUSS][DOCS] Revert a change

[Dmitry Blotsky]

@fil: why is reworking the docs repo needed for automatic deployment?

@steve: could you merge it then? I'm far too rusty on my Cordova-ing to 
remember how to set up my remotes to push to the ASF repo, sorry. :(

Kindly,
Dmitry

> On Sep 13, 2017, at 1:08 PM, Filip Maj  wrote:
> 
> We have an issue posted to make docs publishing automatic:
> https://issues.apache.org/jira/browse/CB-13162
> 
> Not to derail the topic, but there is a longer wishlist in that issue,
> and I do think achieving the goals in that issue would require
> reworking the docs repository quite a bit. We can discuss details in
> the issue thread.
> 
> On Wed, Sep 13, 2017 at 9:47 AM, Dmitry Blotsky
>  wrote:
>> Yes, ideally our deployment process should be automated. Also, it should 
>> *not* be an SVN commit. It should be an rsync or an scp command. I would 
>> support any initiatives to move to either one of those. If we had automated 
>> deployment, this discussion would be moot.
>> 
>> How much would it cost us to just have a VPS with nginx?
>> 
>> Switching to the topic of deployment docs now. Thanks, Shaz, for bringing 
>> this up in discussion. My opinion was that we shouldn't have impactful 
>> commands be copy-paste-able, which is why I had the instruction to commit in 
>> paragraph text. I think that if a committer doesn't read the full text of 
>> the deployment docs, *they should not be deploying*. I can see the argument 
>> that if they do read the text but just don't know *how* to commit in SVN, 
>> it's annoying to search. However at the top of that section is an explicit 
>> link to a quick SVN tutorial. I understand that not everyone reads the fine 
>> print, but IMO committers should, and we should explicitly discourage that 
>> behaviour.
>> 
>> Ultimately I'm going to defer to Shaz here, but I think it's important to 
>> consider the benefits of making deployment *feel* more serious by making 
>> RTFD necessary.
>> 
>> Kindly,
>> Dmitry
>> 
>>> On Sep 13, 2017, at 6:30 AM, Jan Piotrowski  wrote:
>>> 
>>> I am actually surprised deploying is a manual process at all.
>>> Having read the steps, I understand why of course.
>>> 
>>> As a person that jumps in on all kinds of projects, I absolutely
>>> prefer docs that list each and every little step needed (including all
>>> the `cd` etc).
>>> 
>>> The need for manual steps or checks could be emphasized by using a
>>> numbered list or checklist for the individual steps.
>>> 
>>> (Will this stay on SVN even after the repo switch to Github? Merging
>>> and `gh-pages` is so nice and simple)
>>> 
>>> -J
>>> 
>>> 2017-09-13 9:02 GMT+02:00 Shazron :
 This relates solely to instructions on how to *build* the site, and not the
 contents of the site itself.
 
 Bringing this up here for discussion since a committer wants to revert a
 change by another committer, and there is potential for disagreement.
 
 The pull request to revert is here:
 https://github.com/apache/cordova-docs/pull/729
 
 There has been discussion on the original change here:
 https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94
 
 Two issues here:
 1. The change from `gulp build --prod` to `npm run serve`
 2. This instruction here (not reverted in the PR):
 https://github.com/apache/cordova-docs/commit/d61f3ddc84dac4b013c0607230b9cf10921a416b
 
 Issue (1) has some discussion in the GH link above for the original change.
 
 Issue (2) there was some discussion in the Cordova Slack, that the reason
 the `svn commit` wasn't there in the first place is to prevent copy/paste
 of the commands without going through the changes step by step since
 deploying to a site is an expensive operation that can screw up the site if
 proper care was not done.
 
 My reason for adding the command was that the instructions are not complete
 (when I had to do it myself when updating the docs for cordova-ios
 release). I understand the rationale, but the instructions seem incomplete
 (especially for new committers that haven't heard of SVN, I know they can
 Google it, but that's more friction) and my other reason is: we should
 trust that committers will do the right thing.
 
 Not to make a mountain out of a mole-hill but it's important that these
 revert discussions be out in the open so as misunderstandings/hurt feelings
 don't occur, and we can nip it in the bud.
 
 Thoughts from the community?
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, 

Re: [DISCUSS][DOCS] Revert a change

[Steven Gill]

PR looks fine to me. Keep the svn commit stuff. Lets merge and move on

On Wed, Sep 13, 2017 at 10:08 AM, Filip Maj  wrote:

> We have an issue posted to make docs publishing automatic:
> https://issues.apache.org/jira/browse/CB-13162
>
> Not to derail the topic, but there is a longer wishlist in that issue,
> and I do think achieving the goals in that issue would require
> reworking the docs repository quite a bit. We can discuss details in
> the issue thread.
>
> On Wed, Sep 13, 2017 at 9:47 AM, Dmitry Blotsky
>  wrote:
> > Yes, ideally our deployment process should be automated. Also, it should
> *not* be an SVN commit. It should be an rsync or an scp command. I would
> support any initiatives to move to either one of those. If we had automated
> deployment, this discussion would be moot.
> >
> > How much would it cost us to just have a VPS with nginx?
> >
> > Switching to the topic of deployment docs now. Thanks, Shaz, for
> bringing this up in discussion. My opinion was that we shouldn't have
> impactful commands be copy-paste-able, which is why I had the instruction
> to commit in paragraph text. I think that if a committer doesn't read the
> full text of the deployment docs, *they should not be deploying*. I can see
> the argument that if they do read the text but just don't know *how* to
> commit in SVN, it's annoying to search. However at the top of that section
> is an explicit link to a quick SVN tutorial. I understand that not everyone
> reads the fine print, but IMO committers should, and we should explicitly
> discourage that behaviour.
> >
> > Ultimately I'm going to defer to Shaz here, but I think it's important
> to consider the benefits of making deployment *feel* more serious by making
> RTFD necessary.
> >
> > Kindly,
> > Dmitry
> >
> >> On Sep 13, 2017, at 6:30 AM, Jan Piotrowski 
> wrote:
> >>
> >> I am actually surprised deploying is a manual process at all.
> >> Having read the steps, I understand why of course.
> >>
> >> As a person that jumps in on all kinds of projects, I absolutely
> >> prefer docs that list each and every little step needed (including all
> >> the `cd` etc).
> >>
> >> The need for manual steps or checks could be emphasized by using a
> >> numbered list or checklist for the individual steps.
> >>
> >> (Will this stay on SVN even after the repo switch to Github? Merging
> >> and `gh-pages` is so nice and simple)
> >>
> >> -J
> >>
> >> 2017-09-13 9:02 GMT+02:00 Shazron :
> >>> This relates solely to instructions on how to *build* the site, and
> not the
> >>> contents of the site itself.
> >>>
> >>> Bringing this up here for discussion since a committer wants to revert
> a
> >>> change by another committer, and there is potential for disagreement.
> >>>
> >>> The pull request to revert is here:
> >>> https://github.com/apache/cordova-docs/pull/729
> >>>
> >>> There has been discussion on the original change here:
> >>> https://github.com/apache/cordova-docs/commit/
> 96c5ab0f98c0b62160661dcd9a9db5549fe43f94
> >>>
> >>> Two issues here:
> >>> 1. The change from `gulp build --prod` to `npm run serve`
> >>> 2. This instruction here (not reverted in the PR):
> >>> https://github.com/apache/cordova-docs/commit/
> d61f3ddc84dac4b013c0607230b9cf10921a416b
> >>>
> >>> Issue (1) has some discussion in the GH link above for the original
> change.
> >>>
> >>> Issue (2) there was some discussion in the Cordova Slack, that the
> reason
> >>> the `svn commit` wasn't there in the first place is to prevent
> copy/paste
> >>> of the commands without going through the changes step by step since
> >>> deploying to a site is an expensive operation that can screw up the
> site if
> >>> proper care was not done.
> >>>
> >>> My reason for adding the command was that the instructions are not
> complete
> >>> (when I had to do it myself when updating the docs for cordova-ios
> >>> release). I understand the rationale, but the instructions seem
> incomplete
> >>> (especially for new committers that haven't heard of SVN, I know they
> can
> >>> Google it, but that's more friction) and my other reason is: we should
> >>> trust that committers will do the right thing.
> >>>
> >>> Not to make a mountain out of a mole-hill but it's important that these
> >>> revert discussions be out in the open so as misunderstandings/hurt
> feelings
> >>> don't occur, and we can nip it in the bud.
> >>>
> >>> Thoughts from the community?
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> 

[GitHub] cordova-docs issue #729: Fixed up 'deployment' docs in README.md.

[stevengill]

Github user stevengill commented on the issue:

https://github.com/apache/cordova-docs/pull/729
  
LGTM. 

I personally prefer `npm run serve` over `node_modules/.bin/gulp build 
--prod` but can deal with it.


---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS][DOCS] Revert a change

[Filip Maj]

We have an issue posted to make docs publishing automatic:
https://issues.apache.org/jira/browse/CB-13162

Not to derail the topic, but there is a longer wishlist in that issue,
and I do think achieving the goals in that issue would require
reworking the docs repository quite a bit. We can discuss details in
the issue thread.

On Wed, Sep 13, 2017 at 9:47 AM, Dmitry Blotsky
 wrote:
> Yes, ideally our deployment process should be automated. Also, it should 
> *not* be an SVN commit. It should be an rsync or an scp command. I would 
> support any initiatives to move to either one of those. If we had automated 
> deployment, this discussion would be moot.
>
> How much would it cost us to just have a VPS with nginx?
>
> Switching to the topic of deployment docs now. Thanks, Shaz, for bringing 
> this up in discussion. My opinion was that we shouldn't have impactful 
> commands be copy-paste-able, which is why I had the instruction to commit in 
> paragraph text. I think that if a committer doesn't read the full text of the 
> deployment docs, *they should not be deploying*. I can see the argument that 
> if they do read the text but just don't know *how* to commit in SVN, it's 
> annoying to search. However at the top of that section is an explicit link to 
> a quick SVN tutorial. I understand that not everyone reads the fine print, 
> but IMO committers should, and we should explicitly discourage that behaviour.
>
> Ultimately I'm going to defer to Shaz here, but I think it's important to 
> consider the benefits of making deployment *feel* more serious by making RTFD 
> necessary.
>
> Kindly,
> Dmitry
>
>> On Sep 13, 2017, at 6:30 AM, Jan Piotrowski  wrote:
>>
>> I am actually surprised deploying is a manual process at all.
>> Having read the steps, I understand why of course.
>>
>> As a person that jumps in on all kinds of projects, I absolutely
>> prefer docs that list each and every little step needed (including all
>> the `cd` etc).
>>
>> The need for manual steps or checks could be emphasized by using a
>> numbered list or checklist for the individual steps.
>>
>> (Will this stay on SVN even after the repo switch to Github? Merging
>> and `gh-pages` is so nice and simple)
>>
>> -J
>>
>> 2017-09-13 9:02 GMT+02:00 Shazron :
>>> This relates solely to instructions on how to *build* the site, and not the
>>> contents of the site itself.
>>>
>>> Bringing this up here for discussion since a committer wants to revert a
>>> change by another committer, and there is potential for disagreement.
>>>
>>> The pull request to revert is here:
>>> https://github.com/apache/cordova-docs/pull/729
>>>
>>> There has been discussion on the original change here:
>>> https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94
>>>
>>> Two issues here:
>>> 1. The change from `gulp build --prod` to `npm run serve`
>>> 2. This instruction here (not reverted in the PR):
>>> https://github.com/apache/cordova-docs/commit/d61f3ddc84dac4b013c0607230b9cf10921a416b
>>>
>>> Issue (1) has some discussion in the GH link above for the original change.
>>>
>>> Issue (2) there was some discussion in the Cordova Slack, that the reason
>>> the `svn commit` wasn't there in the first place is to prevent copy/paste
>>> of the commands without going through the changes step by step since
>>> deploying to a site is an expensive operation that can screw up the site if
>>> proper care was not done.
>>>
>>> My reason for adding the command was that the instructions are not complete
>>> (when I had to do it myself when updating the docs for cordova-ios
>>> release). I understand the rationale, but the instructions seem incomplete
>>> (especially for new committers that haven't heard of SVN, I know they can
>>> Google it, but that's more friction) and my other reason is: we should
>>> trust that committers will do the right thing.
>>>
>>> Not to make a mountain out of a mole-hill but it's important that these
>>> revert discussions be out in the open so as misunderstandings/hurt feelings
>>> don't occur, and we can nip it in the bud.
>>>
>>> Thoughts from the community?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS][DOCS] Revert a change

[Dmitry Blotsky]

Yes, ideally our deployment process should be automated. Also, it should *not* 
be an SVN commit. It should be an rsync or an scp command. I would support any 
initiatives to move to either one of those. If we had automated deployment, 
this discussion would be moot.

How much would it cost us to just have a VPS with nginx?

Switching to the topic of deployment docs now. Thanks, Shaz, for bringing this 
up in discussion. My opinion was that we shouldn't have impactful commands be 
copy-paste-able, which is why I had the instruction to commit in paragraph 
text. I think that if a committer doesn't read the full text of the deployment 
docs, *they should not be deploying*. I can see the argument that if they do 
read the text but just don't know *how* to commit in SVN, it's annoying to 
search. However at the top of that section is an explicit link to a quick SVN 
tutorial. I understand that not everyone reads the fine print, but IMO 
committers should, and we should explicitly discourage that behaviour.

Ultimately I'm going to defer to Shaz here, but I think it's important to 
consider the benefits of making deployment *feel* more serious by making RTFD 
necessary.

Kindly,
Dmitry

> On Sep 13, 2017, at 6:30 AM, Jan Piotrowski  wrote:
> 
> I am actually surprised deploying is a manual process at all.
> Having read the steps, I understand why of course.
> 
> As a person that jumps in on all kinds of projects, I absolutely
> prefer docs that list each and every little step needed (including all
> the `cd` etc).
> 
> The need for manual steps or checks could be emphasized by using a
> numbered list or checklist for the individual steps.
> 
> (Will this stay on SVN even after the repo switch to Github? Merging
> and `gh-pages` is so nice and simple)
> 
> -J
> 
> 2017-09-13 9:02 GMT+02:00 Shazron :
>> This relates solely to instructions on how to *build* the site, and not the
>> contents of the site itself.
>> 
>> Bringing this up here for discussion since a committer wants to revert a
>> change by another committer, and there is potential for disagreement.
>> 
>> The pull request to revert is here:
>> https://github.com/apache/cordova-docs/pull/729
>> 
>> There has been discussion on the original change here:
>> https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94
>> 
>> Two issues here:
>> 1. The change from `gulp build --prod` to `npm run serve`
>> 2. This instruction here (not reverted in the PR):
>> https://github.com/apache/cordova-docs/commit/d61f3ddc84dac4b013c0607230b9cf10921a416b
>> 
>> Issue (1) has some discussion in the GH link above for the original change.
>> 
>> Issue (2) there was some discussion in the Cordova Slack, that the reason
>> the `svn commit` wasn't there in the first place is to prevent copy/paste
>> of the commands without going through the changes step by step since
>> deploying to a site is an expensive operation that can screw up the site if
>> proper care was not done.
>> 
>> My reason for adding the command was that the instructions are not complete
>> (when I had to do it myself when updating the docs for cordova-ios
>> release). I understand the rationale, but the instructions seem incomplete
>> (especially for new committers that haven't heard of SVN, I know they can
>> Google it, but that's more friction) and my other reason is: we should
>> trust that committers will do the right thing.
>> 
>> Not to make a mountain out of a mole-hill but it's important that these
>> revert discussions be out in the open so as misunderstandings/hurt feelings
>> don't occur, and we can nip it in the bud.
>> 
>> Thoughts from the community?
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-inappbrowser issue #210: CB-12367: Modernize styling of iOS I...

[artyom-dorokhov]

Github user artyom-dorokhov commented on the issue:

https://github.com/apache/cordova-plugin-inappbrowser/pull/210
  
@timbru31 thanks for the tip, but inappbrowser can inject js/css on a 
third-party page and it's the main point of using it.


---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-inappbrowser issue #210: CB-12367: Modernize styling of iOS I...

[timbru31]

Github user timbru31 commented on the issue:

https://github.com/apache/cordova-plugin-inappbrowser/pull/210
  
@artyom-dorokhov you might want to check out 
https://github.com/EddyVerbruggen/cordova-plugin-safariviewcontroller


---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-inappbrowser issue #210: CB-12367: Modernize styling of iOS I...

[artyom-dorokhov]

Github user artyom-dorokhov commented on the issue:

https://github.com/apache/cordova-plugin-inappbrowser/pull/210
  
i'd love to have it merged. current version of inappbrowser with its 
styling looks like from 90's


---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-console issue #25: CB-13170 - final changes and release of po...

[janpio]

Github user janpio commented on the issue:

https://github.com/apache/cordova-plugin-console/pull/25
  
Nice. 

Does this mean that the 2.0.0 of the console plugin can be installed on 
`cordova-ios` 4.5.0 without causing the build problems?


---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS][DOCS] Revert a change

[Jan Piotrowski]

I am actually surprised deploying is a manual process at all.
Having read the steps, I understand why of course.

As a person that jumps in on all kinds of projects, I absolutely
prefer docs that list each and every little step needed (including all
the `cd` etc).

The need for manual steps or checks could be emphasized by using a
numbered list or checklist for the individual steps.

(Will this stay on SVN even after the repo switch to Github? Merging
and `gh-pages` is so nice and simple)

-J

2017-09-13 9:02 GMT+02:00 Shazron :
> This relates solely to instructions on how to *build* the site, and not the
> contents of the site itself.
>
> Bringing this up here for discussion since a committer wants to revert a
> change by another committer, and there is potential for disagreement.
>
> The pull request to revert is here:
> https://github.com/apache/cordova-docs/pull/729
>
> There has been discussion on the original change here:
> https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94
>
> Two issues here:
> 1. The change from `gulp build --prod` to `npm run serve`
> 2. This instruction here (not reverted in the PR):
> https://github.com/apache/cordova-docs/commit/d61f3ddc84dac4b013c0607230b9cf10921a416b
>
> Issue (1) has some discussion in the GH link above for the original change.
>
> Issue (2) there was some discussion in the Cordova Slack, that the reason
> the `svn commit` wasn't there in the first place is to prevent copy/paste
> of the commands without going through the changes step by step since
> deploying to a site is an expensive operation that can screw up the site if
> proper care was not done.
>
> My reason for adding the command was that the instructions are not complete
> (when I had to do it myself when updating the docs for cordova-ios
> release). I understand the rationale, but the instructions seem incomplete
> (especially for new committers that haven't heard of SVN, I know they can
> Google it, but that's more friction) and my other reason is: we should
> trust that committers will do the right thing.
>
> Not to make a mountain out of a mole-hill but it's important that these
> revert discussions be out in the open so as misunderstandings/hurt feelings
> don't occur, and we can nip it in the bud.
>
> Thoughts from the community?

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[DOCS] Removing the last remnants of React

[Shazron]

Thanks to Tommy, one of Cordova's committers, for this!
https://github.com/apache/cordova-docs/pull/728

This removes our only use of React, in plugins.cordova.io
This removal is required by Apache Legal:
https://issues.apache.org/jira/browse/CB-13025

[DISCUSS][DOCS] Revert a change

[Shazron]

This relates solely to instructions on how to *build* the site, and not the
contents of the site itself.

Bringing this up here for discussion since a committer wants to revert a
change by another committer, and there is potential for disagreement.

The pull request to revert is here:
https://github.com/apache/cordova-docs/pull/729

There has been discussion on the original change here:
https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94

Two issues here:
1. The change from `gulp build --prod` to `npm run serve`
2. This instruction here (not reverted in the PR):
https://github.com/apache/cordova-docs/commit/d61f3ddc84dac4b013c0607230b9cf10921a416b

Issue (1) has some discussion in the GH link above for the original change.

Issue (2) there was some discussion in the Cordova Slack, that the reason
the `svn commit` wasn't there in the first place is to prevent copy/paste
of the commands without going through the changes step by step since
deploying to a site is an expensive operation that can screw up the site if
proper care was not done.

My reason for adding the command was that the instructions are not complete
(when I had to do it myself when updating the docs for cordova-ios
release). I understand the rationale, but the instructions seem incomplete
(especially for new committers that haven't heard of SVN, I know they can
Google it, but that's more friction) and my other reason is: we should
trust that committers will do the right thing.

Not to make a mountain out of a mole-hill but it's important that these
revert discussions be out in the open so as misunderstandings/hurt feelings
don't occur, and we can nip it in the bud.

Thoughts from the community?

Re: [DISCUSS] Plugin release

[Shazron]

Created PR for CB-13170 cordova-plugin-console
https://github.com/apache/cordova-plugin-console/pull/25

On Tue, Sep 12, 2017 at 7:20 AM, Simon MacDonald 
wrote:

> Both of:
>
> cordova-plugin-device-motion
> cordova-plugin-device-orientation
>
> should get their deprecation PR's merge and also released.
>
> Simon Mac Donald
> http://simonmacdonald.com
>
>
> On Mon, Sep 11, 2017 at 7:03 PM, Shazron  wrote:
> > +1 on console. No PRs for that yet though so it's not ready.
> >
> > On Tue, Sep 12, 2017 at 5:46 AM, Steven Gill 
> wrote:
> >
> >> Console should be released too since it has been moved back into ios for
> >> next release. https://issues.apache.org/jira/browse/CB-13170
> >>
> >> On Sep 11, 2017 2:04 PM, "Jesse"  wrote:
> >>
> >> > Android release is dependent on us releasing an
> >> > updated cordova-plugin-compat
> >> >
> >> > Anyone have any reasons to not do a release? Anything outstanding
> >> > anyone wants to get merged in before moving ahead with a plugins
> >> > release? Any other comments on the topic?
> >> >
> >> > Cheers,
> >> >   Jesse
> >> >
> >> >
> >> > @purplecabbage
> >> > risingj.com
> >> >
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

[GitHub] cordova-plugin-console pull request #25: CB-13170 - final changes and releas...

[shazron]

GitHub user shazron opened a pull request:

https://github.com/apache/cordova-plugin-console/pull/25

CB-13170 - final changes and release of post-integration 
cordova-plugin-console

### Platforms affected

cordova-ios, cordova-windows

### What does this PR do?

Prevent installation of this plugin on cordova-ios >= 4.5.0, and 
cordova-windows > 5.0.0

### What testing has been done on this change?

Added the plugin on different platform versions for the affected platforms.

### Checklist
- [X] [Reported an issue](http://cordova.apache.org/contribute/issues.html) 
in the JIRA database
- [X] Commit message follows the format: "CB-3232: (android) Fix bug with 
resolving file paths", where CB- is the JIRA ID & "android" is the platform 
affected.
- [ ] Added automated test coverage as appropriate for this change.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shazron/cordova-plugin-console CB-13170

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-console/pull/25.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #25


commit 316d30b95471dae6f2b38cba9ffde4173014ea2b
Author: Shazron Abdullah 
Date:   2017-09-13T06:39:14Z

CB-13170 - final changes and release of post-integration 
cordova-plugin-console




---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org