Thank you very much for your response. That makes perfect sense, I had forgot about all that Sourceforge offered, and I've never really thought critically of github but its the not and end all be all. Thank you again.
On Fri, Jun 12, 2015 at 4:03 PM, DRC <dcomman...@users.sourceforge.net> wrote: > 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 config > with > > GLX_DRAWABLE_TYPE=GLX_PBUFFER_BIT (assuming that > VGL_DRAWABLE=pbuffer, > > which is the default.) This is incorrect, however, because > regardless > > of the value of VGL_DRAWABLE, VirtualGL still uses Pixmaps on the 3D > X > > server to represent GLX Pixmaps (necessary in order to make > > GLX_EXT_texture_from_pixmap work properly.) Thus, VGL needs to > choose > > an FB config that supports both Pbuffers and Pixmaps. This was > > generally only a problem with nVidia drivers, because they export > > different FB configs for GLX_PBUFFER_BIT and > > GLX_PBUFFER_BIT|GLX_PIXMAP_BIT. > > > > ------------------------------------------------------------------------------ > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users >
------------------------------------------------------------------------------
_______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
