Am 25.05.2021 um 15:11 schrieb Chris Cason:

> I like the idea of turning this on its head - instead of managing users 
> and permissions and merging content from multiple sources, it occurs to 
> me that we could just do it the other way around ... set up the repos on 
> github in a format that would be consumable (even if just by scraping 
> HTTP) that allows the povray.org server to reach-out and ingest it in 
> one step (and rinse lather repeat). github has the infrastructure to 
> manage the users, merges, history, and so forth, thus relieving us of 
> having to do it. It also makes it easier for someone to contribute (all 
> they need is a github account and an understanding of the way the repo 
> is laid out in order to contribute. No need to have to create an account 
> on povray.org and ask for edit permissions).

I guess one of those GitHub build tools we're currently using (well, 
last time I checked, anyway) to do the automated build tests (Semaphore, 
AppVeyor or Travis CI) could be enlisted to automate most - if not all - 
of the updating process, if done properly. So eventually, day-to-day 
management of the website might be as easy as QC-ing and merging pull 
requests, and waiting for a bunch of automatically triggered scripts to 
do the rest. I have a hunch that at least AppVeyor would even be able to 
directly publish the results to the web server via FTP.

I'd strongly recommend using a repo strictly separate from the POV-Ray 
source code, for a couple of reasons. But other than that, I guess it 
would be ok to use directories for any further structure needed. One 
directory branch for the HOF, another one for link collections, and so on.

(I don't think it makes sense to use separate repos for the individual 
subsections of the Website, even though they may need entirely different 
processes to digest them into HTML files. At the end of the day, they'll 
presumably all share the same mechanism by which they will be published 
to the server.)

Post a reply to this message