cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Blotsky <dmitry.blot...@gmail.com>
Subject Re: [DISCUSS][DOCS] Revert a change
Date Wed, 13 Sep 2017 19:37:08 GMT
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 <maj.fil@gmail.com> 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
> <dmitry.blotsky@gmail.com> 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 <maj.fil@gmail.com> 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
>>> <dmitry.blotsky@gmail.com> 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 <piotrowski@gmail.com>
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 <shazron@gmail.com>:
>>>>>> 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-unsubscribe@cordova.apache.org
>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
> 


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


Mime
View raw message