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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 <[email protected]>: >>>>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
