Create a self-contained mini-docs site

[JJ]

The problem

Right now, site-generation tools are tested by actually generating the site and fixing stuff if something fails. There's no comprehensive test suite, some doc-site-specs, that allow someone to say "that's fine" if htmlify.p6 or attendant modules (such as Perl6::Documentable) are modified. There's no spec either, so the best we can do now is to say "It seems to work the way it did before".
That makes things like #1823, #2503 or #1937 difficult or even impossible, since it's almost impossible to know if whatever we come up with is actually plug-in compatible with whatever we were running before. Also things like #1959 #1809 #2527 are discovered from time to time, with only patches available (which sometimes break a different thing)

Suggestions

Create a mini-docs repo, self-contained and, if possible, useful enough, that can be used to test all and everything related to docs.perl6.org.

[tbrowder]

I concur, and it should be on a fully capable host. Does the droplet need expanding in some measure? Should more people be brought on board? Do we need a more traditional host (i.e., a bare metal serever independent of any specific provider)?

[JJ]

I don't think so. The whole point is that the whole infrastructure should be defined by code.

[finanalyst]

I'm attempting to do this already. May be 80% complete.

Please look at new doc repo

I have begun to put this on the droplet. Infrastructure for droplet missing as I write

[JJ]

I was thinking more about real documentation, that we can use for testing. Without it, it's impossible to know if the new rendering engine is providing the same functionality it did before.

[finanalyst]

JJ,
We discussed a possible test file. I thought you mentioned 'Strings', but there is no 'Language/Strings.pods'. There is a 'Type/Str.pod6' .

I cannot find our discussion, so I can't check.

[finanalyst]

I've run a contents analysis on all the sources, followed by a frequency across the whole collection. The results are (and my comments):
Pod::Block::Named 365 # meaning 365 files - all of them - have an instance of this Block
Pod::Block::Para 365
Pod::Block::Code 357
Pod::Heading 308
Pod::FormattingCode｢C｣ 297
Pod::FormattingCode｢L｣ 249
Pod::FormattingCode｢I｣ 116
Pod::FormattingCode｢B｣ 90
Pod::FormattingCode｢X｣ 85
Pod::Item 43
Pod::Block::Table 26
Pod::Block::Comment 20
Pod::FormattingCode｢N｣ 12
Pod::FormattingCode｢R｣ 3
Pod::FormattingCode｢Z｣ 3
Pod::FormattingCode｢F｣ 1 # F does not exist. I have removed it from 101-basics.pod6
Pod::Defn 1 # only pod.pod6
Pod::FormattingCode｢E｣ 1 # only pod.pod6

[JJ]

Actually, the whole hierarchy related to strings, including "Stringy" and "Cool" El lun., 7 ene. 2019 a las 7:32, Richard Hainsworth (< notifications@github.com>) escribió:

…

I've run a contents analysis on all the sources, followed by a frequency across the whole collection. The results are (and my comments): Pod::Block::Named 365 # meaning 365 files - all of them - have an instance of this Block Pod::Block::Para 365 Pod::Block::Code 357 Pod::Heading 308 Pod::FormattingCode｢C｣ 297 Pod::FormattingCode｢L｣ 249 Pod::FormattingCode｢I｣ 116 Pod::FormattingCode｢B｣ 90 Pod::FormattingCode｢X｣ 85 Pod::Item 43 Pod::Block::Table 26 Pod::Block::Comment 20 Pod::FormattingCode｢N｣ 12 Pod::FormattingCode｢R｣ 3 Pod::FormattingCode｢Z｣ 3 Pod::FormattingCode｢F｣ 1 # F does not exist. I have removed it from 101-basics.pod6 Pod::Defn 1 # only pod.pod6 Pod::FormattingCode｢E｣ 1 # only pod.pod6 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2529 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAB9Gh-pqRnNMd3vxhDsO1HRiK4DQJdks5vAun8gaJpZM4Zk5Wj> .

-- JJ