|
|
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
|
|