I haven't read 'useful macros' thread yet so please excuse me if that 
thread already involves the following concept.

It's one that germinated when I was doing the server re-build and 
thinking of ways to avoid having heaps and heaps of PHP code to maintain 
stuff like a HOF, texture library, users and permissions for each, audit 
trail, undo, copyright assignments and so forth (we don't have most of 
those things, but if the community is to help manage the site we need 
them, or something that achieves the same end).

Put another way, it's been said before that we ought to take more help 
from regular newsgroup users; the problem has generally being writing 
the infrastructure to allow e.g. editing of the HOF, links (though the 
latter already has some support).

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 bet we could find a way of handling the HOF this way. With a few 
trusted community members in charge of QC and, accepting pull requests, 
and maintaining meta-data when needed, the HOF would (from the point of 
view of us) become self-managing (because I sure as heck don't do it now).

IF that works, well then there's the link collection, textures, what 
else? What can you think up?

-- Chris

Post a reply to this message

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

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I haven't read 'useful macros' thread yet so please excuse me if that
> thread already involves the following concept.
>
> It's one that germinated when I was doing the server re-build and
> thinking of ways to avoid having heaps and heaps of PHP code to maintain
> stuff like a HOF, texture library, users and permissions for each, audit
> trail, undo, copyright assignments and so forth (we don't have most of
> those things, but if the community is to help manage the site we need
> them, or something that achieves the same end).
>
> Put another way, it's been said before that we ought to take more help
> from regular newsgroup users; the problem has generally being writing
> the infrastructure to allow e.g. editing of the HOF, links (though the
> latter already has some support).
>
> 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 bet we could find a way of handling the HOF this way. With a few
> trusted community members in charge of QC and, accepting pull requests,
> and maintaining meta-data when needed, the HOF would (from the point of
> view of us) become self-managing (because I sure as heck don't do it now).
>
> IF that works, well then there's the link collection, textures, what
> else? What can you think up?
>
> -- Chris

Hi, of course I can just give the opinion of some random user : regardless of my
having mixed (apriori) feelings about github*, this sounds to my profane ears
like a great idea. If you decide that's how contributions, have to happen, I
would try to create an account and strive to learn it just for the purpose of
continuing, as little as it may be, my humble contribution to the links
repository. I like the wiki though.(especially the new one).

I can see two areas of possible benefit from this :
-The hall of fame looks perfect indeed as one should really weight whether the
currently very high standard of the hof is met by some candidate image. and I
imagine that rather heavy process forcing more thought into the act than a mere
gallery push.

-What about duplicating there the IRTC archives entries that have scene files ?
giving them a new ventilation, maybe some of the awesome scenes in there might
inspire some people to update them that way?

*the mixed feeling is only some slight fear about the github site being owned by
a company with a history of monopolistic practices (Microsoft) though they did
show a lot otherwise recently. But no one seems to question the risk of putting
the whole open source community in the palm of that hand. Then again, massive
number of users is probably a good point.

I imagine that if you propose this there is already a positive return of
experience from having POV-Ray code itself on Github?

Post a reply to this message

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). [...]

It might be worth investigating whether GitHub Pages would be a way to 
go for this:

https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages

Post a reply to this message