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 3.7.0.0 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 
tracker.

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

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 
v3.7.0.0. 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