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