Am 05.08.2021 um 18:02 schrieb jr:
> anyway, the whole thing makes me wonder why you .. bother. *NIX-ness is not a
> high priority for you, I feel, so why even have tarballs? would just "git
> clone" not be preferential?
I think that's a severe misunderstanding.
My *NIX expertise is very low, that's why I'm not doing much for *NIX.
That doesn't mean I don't care. It just means I can't do.
> (this rant is "tainted" -- probably -- by your mentioning that even the POV-Ray
> development code resides "in the cloud" now rather than on own(ed) server(s))
It has been ever since we moved to a Git-based solution, right at the
time of the 184.108.40.206 release.
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.
As a matter of fact, *NIX-ness might have been the feature to benefit
most. With the dev team stocked pretty much with pure Windows jockeys,
automated test builds were the only thing that had us on our toes
regarding *NIX-incompatibilities. Setting up such facilities on our own
would have required quite the effort.
Automated test builds also helped a lot to get us through the times when
C++11 and clang both started to see widespread use, sending additional
ripples across the boost library, and opened up new portability pitfalls
due to incomatibilities between ever shifting boost versions, certain
constructs that turned out to no longer work in C++11, and the like.
With us Windows jockeys having no (or only cumbersome) access to a truly
C++11-compatible (let alone C++11-strict) development environment back
then, the availability of not just one but three(!) independent
free-for-open-source hosted build test services was invaluable to keep
POV-Ray compatible with all the fast-changing world of C++ back then,
both the established and the emerging.
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
And the fact that *NIX tarballs are back on the menu is also courtesy of
GitHub, because as we now migrated all the automated build tests from
3rd party services to GitHub's new own, we found that we could easily do
additional stuff whenever we were to auto-build Windows binaries. Even
stuff that would require a *NIX machine to run. (Or a MacOS machine, for
that matter, but that's not a thing that has manifested so far). So we
added *NIX tarballs to that build process.
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
Which is another boon of GitHub: It is so much easier to set up a new
release there, with any arbitrary set of associated downloadables, than
it would be on our own web server.
Which is what has gotten you folks each and every alpha release since
v220.127.116.11. I have no access to the web server to bundle up and publish
releases there, and I wouldn't have dared to bother Chris with anything
other than betas or better. Let alone that it would have taken a couple
of days minimum (if not weeks) for each such release to eventually make
it onto some downloadable page.
I wouldn't even have seen the benefit of such releases in the first
place. It was more a matter of, "hey, we can do this on a regular basis
with almost zero effort, so why not."
And I won't even mention the occasional experimental build, such as the
OpenType support builds.
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.
Post a reply to this message