What recent behavior? I've been hosting VirtualGL and TurboVNC on SF
for 10+ years, and apart from a little bit of growing pain associated
with migrating to Allura, I've had no major issues with that platform.
Github is hot right now, but in the 20 years I've been doing
professional software development, I've seen sites like that come and
go. Give it a couple of more years before I fully trust it.
Github definitely does do a lot of things better than SourceForge. I
love its web interface-- I just wish it weren't built around git. :) I
just can't stand working with git on a day-to-day basis. It's very
non-intuitive for me, and this article echoes a few of the reasons why:
http://www.peterlundgren.com/blog/on-gits-shortcomings/
On the rare occasions that I've tried to do any serious development with
git, I've managed to screw things up pretty badly, mostly vis-a-vis
branching and merging (managed to accidentally delete hours of work on
more than one occasion.) I am just more comfortable with a centralized
repository and a bare-metal connection with the revision control server.
When I tell subversion to do something, I am confident that it does
exactly what I instruct. When I check something in, I'm confident that
it is stored in the database and can't be accidentally deleted. Git
seems to want to second-guess me too much. I find some operations in
git (such as merging) to be more difficult than they really should be.
There are some workflows for which I prefer using git-svn as a client,
but I prefer subversion on the back end, and I usually prefer it as a
client as well. I am used to working with revision numbers. I like
being able to edit revision logs after the fact, if information changed
that was relevant to the revision.
I get why it's a lot easier to collaborate with git, but with a project
like this that has one main developer and only one or two occasional
contributors, there is no real need for that kind of collaboration. I
don't think moving to github would make VirtualGL developers magically
appear. It's a niche product, at the end of the day.
Also, I like the integrated nature of SourceForge, in that we can host
mailing lists and discussion forums and bug trackers and file releases
and revision control from the same site.
On 6/12/15 3:47 PM, Morgan Ross wrote:
Have you considered migrating to github from sourceforge, in light of
their recent behavior? Sorry if this has already been addressed.
On Fri, Jun 12, 2015 at 8:19 AM, DRC dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
http://sourceforge.net/projects/virtualgl/files/2.4.1/
Packaging changes:
These packages were built with libjpeg-turbo 1.4.1:
http://sourceforge.net/projects/libjpeg-turbo/files/1.4.1/
This improves performance on 64-bit Mac clients, relative to
VirtualGL 2.4.
Significant changes since 2.4:
[1] When an application doesn't explicitly specify its visual
requirements by calling glXChooseVisual()/glXChooseFBConfig(), the
default GLX framebuffer config that VirtualGL assigns to it now contains
a stencil buffer. This eliminates the need to specify
VGL_DEFAULTFBCONFIG=GLX_STENCIL_SIZE,8 with certain applications
(previously necessary when running Abaqus v6 and MAGMA5.)
[2] VirtualGL will no longer advertise that it supports the
GLX_ARB_create_context and GLX_ARB_create_context_profile extensions
unless the underlying OpenGL library exports the
glXCreateContextAttribsARB() function.
[3] Fixed Invalid MIT-MAGIC-COOKIE-1 errors that would prevent
VirtualGL from working when vglconnect was used to connect to a
VirtualGL server from a client running Cygwin/X.
[4] If a 3D application is rendering to the front buffer and one of the
end-of-frame trigger functions (glFlush()/glFinish()/glXWaitGL()) is
called, VirtualGL will no longer read back the framebuffer unless the
render mode is GL_RENDER. Reading back the front buffer when the render
mode is GL_SELECT or GL_FEEDBACK is not only unnecessary, but it was
known to cause a GLXBadContextState error with newer nVidia drivers
(340.xx and later) in certain cases.
[5] Fixed a deadlock that occurred in the multi-threaded rendering test
of fakerut when it was run with the XCB interposer enabled. This was
due to VirtualGL attempting to handle XCB events when Xlib owned the
event queue. It is possible that this issue affected or would have
affected real-world applications as well.
[6] Fixed an issue that caused certain 3D applications (observed with
CAESES/FFW, although others were possibly affected as well) to abort
with ERROR: in TempContext-- Could not bind OpenGL context to window
(window may may have disappeared). When the 3D application called
glXChooseVisual(), VirtualGL was choosing a corresponding FB
