On 8/6/21 1:46 PM, clipka wrote:
> To cram that content into the Wiki would have required writing import 
> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import 
> format, while presumably Jim has just as much knowledge about the format 
> generated by said tool (beyond the fact that it's HTML, of course).

don't even /try/ to involve me. haven't you guys noticed that i've not 
been replying to the documentation updates / corrections that y'all have 
been flinging over the wall. i've been trying to step away from the 
curator role that i didn't really sign up for. hell...  i /still/ need 
to finish debugging the php / mysql changes to wikidocgen ( after server 
crash ) so that ought to be a clue as to my motivation.

Post a reply to this message

On 7/08/2021 18:12, clipka wrote:
> Did I mention that I do not have access to the POV-Ray web server? Nor 
> do I really care to get such access. It's not the kind of work I want to 
> put on my plate. I'm no good at it.

Yeah I don't blame you. Before the crash the old system was hanging on 
with chewing gum and sticky-tape. Now that we're up to date with all the 
latest libs and PHP version it's a little more amenable to having 
another person edit stuff, but it's still very much a case of 'ssh into 
the server and edit the PHP pages with VI'. All pages require 
interleaving of PHP and HTML as the website theme and individual page 
sections are pulled in from a common PHP library.

Oh, and there's no staging environment so all edits go live instantly 
:). If I forget to close a PHP statement or leave off a semicolon the 
entire page breaks (or the entire site if it's one of our include files ...)

I could set up a staging environment now that I've got plenty of disk 
space and have started managing the website with git, but I didn't think 
there was a pressing need (and your above comment confirms that).

-- Chris

Post a reply to this message

Am 07.08.2021 um 11:58 schrieb Ash Holsenback:
> On 8/6/21 1:46 PM, clipka wrote:
>> To cram that content into the Wiki would have required writing import 
>> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import 
>> format, while presumably Jim has just as much knowledge about the 
>> format generated by said tool (beyond the fact that it's HTML, of 
>> course).
> 
> don't even /try/ to involve me. haven't you guys noticed that i've not 
> been replying to the documentation updates / corrections that y'all have 
> been flinging over the wall. i've been trying to step away from the 

> to finish debugging the php / mysql changes to wikidocgen ( after server 
> crash ) so that ought to be a clue as to my motivation.

Sounds like great fun...
Not.

Don't worry, all I wanted to hint at was that even the two people who 
would know most about the matter are nowhere close to a position of just 
flicking a switch and magically importing those developers' docs into 
the Wiki. And that therefore, given all the other considerations 
besides, it makes no sense whatsoever to invest any time into even trying.

Post a reply to this message

On 7/08/2021 19:58, Ash Holsenback wrote:

> to finish debugging the php / mysql changes to wikidocgen ( after server 
> crash ) so that ought to be a clue as to my motivation.

I can take a look at that if you like. Was going to spend Sunday doing 
server maintenance.

-- Chris

Post a reply to this message

On 8/7/21 9:26 AM, Chris Cason wrote:
> On 7/08/2021 19:58, Ash Holsenback wrote:

>> to finish debugging the php / mysql changes to wikidocgen ( after 
>> server crash ) so that ought to be a clue as to my motivation.
> 
> I can take a look at that if you like. Was going to spend Sunday doing 
> server maintenance.
> 
> -- Chris

appreciate the offer... i'll manage. my only excuse is being lazy.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> ...
> Fossil? The first time I've ever heard of it was when you just brought
> it up.

a bit like music, there's always artists one has never heard of :-).

fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>


regards, jr.

Post a reply to this message

Am 07.08.2021 um 22:50 schrieb jr:

> fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>

Judging by that description, it looks like it would actually have been 
an inferior choice for us.

POV-Ray has a tradition of being forked, for various purposes, and we 
see that as something to be encouraged. Notable examples from the past 
include MegaPOV, MCPov, and that Special Relativity version of POV-Ray 
someone once made. Post-v3.7 examples include UberPOV, Hgpovray(*), 
qtpov and rpov.

I can't speak for the other fork authors, but to me as the author of 
UberPOV, the simplicity with which changes from official POV-Ray could 
be merged in on a semi-regular basis, while at the same time preventing 
UberPOV's own changes to spill back into the official POV-Ray repo, was 
a great help, and an encouraging factor in the decision to even start 
that fork in the first place. And I guess other people's experience is 
similar (*Hgpovray being an exception here, as the author deliberately 
chose to use a versioning system he's more familiar with).


Some additional points where Fossil would be a poor choice:

- "Drive-by contributions" is something we want to encourage, not 
discourage.

- "Trust over hierarchy" is a luxury we can't afford: POV-Ray's internal 
architecture is so convoluted and complex, our goals of what we want 
that architecture to eveolve into so different from the current status, 
and the road there so vaguely visible, that it is unreasonable to expect 
even the best developers to reliably make good design decisions when 
developing fixes, features or whatever. So no matter how much trust we 
place in their integrity and capabilities, it is prudent we don't just 
accept the result of their work based on implicit trust alone.

Post a reply to this message

in news:web.610ef2315f6dda2a5e0fed26cde94f1@news.povray.org jr wrote:

> fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>
> 

:) I've been using it a lot for years now. Every ctrl-S from many 
programms or crtl-B from the editor creates a new entry in the proper 
fossil. 

-- 
https://ingoogni.nl

Post a reply to this message

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.610ef2315f6dda2a5e0fed26cde94f1@news.povray.org jr wrote:
>
> > fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>
> >
>
> :) I've been using it a lot for years now. ...

</tap-nose>  :-)


regards, jr.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> And to be frank, the GitHub infrastructure around the repo has been
> quite an asset in the development work ever since. With the manpower
> available to us, it would have been impossible to set up (let alone
> maintain!) anything even remotely like it on our own turf.
[...]
> We also got some feedback and contributions via GitHub that we might not
> have gotten otherwise. Certainly not on as large a scale as in CompuServ
> times, but still.
>
> Among those who got into touch with us were the folks who maintain the
> "homebrew" packages to provide *NIX software for MacOS. Which put
> official MacOS compatibility back on the menu, after it had already
> dropped off the back of the truck in the years prior.
[...]

> The issue tracker also proved useful, if only because it meant we no
> longer had to waste time keeping spammers out of our self-hosted bug
> tracker.
[...]
> And a developers' manual, just because we could. I had already set up a
> few scripts and configs for that purpose years ago for my own use, but
> never got around to setting up a channel for publishing the generated
> documents.
[...]
> Even whether beta.1 would be out yet, without GitHub's ease of deploying
> software, is anybody's guess. It might still be in the pipeline between
> me and Chris Cason. Or I might still be procrastinating about even
> actually running the build process on my local machine. Having GitHub
> run it is so much easier and leaves far less room for PEBCAK errors,
> once the process has been set up.
>
>
> There's no fault in being somewhat suspicious of 3rd party services like
> GitHub. But let that not blind you to their benefits.
>
> Division of labour has been one of the most efficient strategies in the
> history of humanity, and this is just another application of that principle.

Thanks for taking the time to explicit all of this ! I wasn't aware that a (3.7)
Homebrew package was available and just added it to the informal wiki
page(https://wiki.povray.org/content/HowTo:Install_POV#Mac_OS.2FX). May we send
the maintainers for it some kind of notification /request about the 3.8 alpha ?

Post a reply to this message