Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andreas Heigl
    @heiglandreas
    Hey Peter :wave:
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    @salathe Hello. Thanks for accepting our invitation. Your opinion in this migration will be very important :blush:
    Danack
    @Danack
    So, a little progress report on tooling. It took me a bit longer than I thought it would to re-understand how the manual gets built and in particular how partial manual builds get built.
    This repo https://github.com/danack/PHPDocTool will do all the stuff necessary to check out the docs, and PHD then render it locally, and watch for any changes on the file system, at which point it will rebuild just the changes.
    The good news is rebuilding just the changes in isolation is really quick (a few seconds) the less good news is that because the build is done in isolation, there is some stuff missing e.g. if you make a change in Imagick::adaptiveBlurImage, that page will be updated.......but it will lose all links to other Imagick methods, because the class index was included in the partial render.
    btw, that tool currently uses git ls-files -m to find the modified files. This apparently makes Docker very angry, and shouldn't be left running indefinitely.
    Danack
    @Danack
    @salathe Do the repos for the doc-base and the PHD renderer have tests setup for them? Obviously using the same code that is actually run to build the manual as for CI and local tools would be good, but I think I'd like to make some changes to configure.php in doc-base, and possibly the PHD renderer to make it possible to i) call them as functions rather than having to invoke them through the command line ii) be able to compile small chunks of the manual, in a way that produces an output that is more like the full manual build rather than the current partial rendering, due to the indexes being lost.
    If they have tests, then making changes would be reasonably safe.....if not, then no.
    Danack
    @Danack
    I'm going to play with the github notifications next and look at rendering pull requests.....I'm going to stick with a separate tool rather than just using Travis for now, as I still think having the build results be almost instantaneous and viewable online will be better than Travis which can lag and would need to have the results pushed somewhere else to be viewed.
    But ....it is possible that I might change my mind and just shove it in favour of Travis.
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    Awesome @Danack, I'll be taking a look into that later
    I've been played with the misspell-fixers and Travis
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    @Danack @nikic @heiglandreas I won’t be able to join you guys tonight. I’m downtown, is heavily raining and I won’t make to home at time 😕
    Andreas Heigl
    @heiglandreas
    Same here sadly. I have a sudden visit of. my parents and can't make it...
    And I didn't get round to testing anything sadly as well. 😔
    Danack
    @Danack
    Well in that case, I'm going to play with my new vaporizer.
    Danack
    @Danack

    FYI What I was going to say tonight was that:

    i) making sure the configure.php in the doc-base repo and the phd render have tests would be a good thing to have done eventually. Currently that code can only be used via the command line, which is slightly annoying, but also the partial render can only render one file at a time, which is quite annoying. Changing that to be better would be not too difficult to do, but obviously would be better once someone has checked that there are enough tests in place to make sure rendering the manual doesn't break.

    ii) I'm going to crack on improving https://github.com/danack/PHPDocTool to make it have a front-end that shows what it's doing (and what was recently rendered), to have a place where you can drop in the url of a github fork of the docs and have it render that before a PR is opened, and anything else sensible I can think of.
    Nikita Popov
    @nikic
    Ooops, missed the time...
    But looks like I didn't really miss anything :D
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    Btw, I'm a little bit absence due to some stuff from work, but, next week, I pretend to re-schedule our Hangouts, so we can align in what step we're in this migration.
    Andreas Heigl
    @heiglandreas
    @carusogabriel Do you want to answer to the mail from Derick about abandoning the Mirrors? Or does not affect us at all? In the end the deployment-process will still be the same....
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    @heiglandreas What email, my friend? It was in some list from php.net?

    Ahh, just saw it in the internals@.

    I don't think that this will affect us.

    @nikic Aren't we using the git.php.net domain for this migration?

    Nikita Popov
    @nikic
    Shouldn't affect us
    Or only in ways that makes things simpler :)
    Andreas Heigl
    @heiglandreas
    Git filter-branch looks like a good way to replace all the SVN-IDs in the history of the non-english languages through the complete history....
    And then it should be possible to run a cront-task that retrieves the new stuff from SVN, replaces the IDs with the hashes and then pushes to the main repo .
    It should be sufficient to run that on an hourly schedule....
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    @heiglandreas Git filter-branch?
    Andreas Heigl
    @heiglandreas
    exactly that.
    it will run the filter on the local copy and then push the altered commits to the upstream repo
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    Awesome! Maybe next week we can Hangout to see the evolution of that?
    Andreas Heigl
    @heiglandreas
    That should be possible. At least I can tell something about the ideas and how far I got until then. Next saturday?
    Or is Thursday better?
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    I can’t Tuesday and Thursday due to English :confused:
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    @/all Let's hangout this weekend to align our evolution on this? :)
    Danack
    @Danack
    Yes.
    Also.....I'm pissed off at docker. I'm pretty sure that we could make a really nice UX for a local editor tool that does things like automatically jumps to the file you've been editing.
    Except that the whole filesystem is just too slow in Docker to be able to watch or handle as many files as there are in the manual.
    So.....i'm chucking all of those ideas away, and reverting to some bash scripts that will run on the host machine instead.
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    That sucks. The UX of the current editor is PITA
    Andreas Heigl
    @heiglandreas
    Sorry for being unresponsive. It's been a hard time the last weeks....
    But I managed to get git filter-branch going. Running it on the german translation took about 15 hours, but now all the Revision-IDs are replaced with the corresponding hashes!
    Now I need to automate that process to only run from the last successfull hash on...
    Andreas Heigl
    @heiglandreas
    And then we need to find a machine to run that on via a cron-job.
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50

    @heiglandreas Don't worry, I believe we all are :)

    Good to know that we achieve that!

    @nikic What is missing from your side?

    Nikita Popov
    @nikic
    I think we mainly need input from @salathe, who is running the mirror right now