>From the point of view of TurboVNC, shipping binaries is essential. Our leading client platform is Windows by a wide margin, and most of our users are corporate and academic interests that may have the ability-- but certainly not the time-- to play with the source. Given how much difficulty that I had with building TigerVNC, I'm not confident that it will go smoothly for an end user, even with our script. Additionally, the build of Xvnc takes *forever*, requires 1.5 gigabytes of disk space, and is likely to encounter dependency issues, etc. This isn't a simple matter of untar/configure/make.
One of the founding principles of the VirtualGL project is to always ship binaries, because our project is very dependent on end users. The key to VirtualGL's stability is that it has been tested by thousands of users on thousands of different applications. Most users that test it aren't developers and wouldn't know how to build the code, so the easier I can make it for them to test, the more stable the code becomes, even though there is technically only one developer. Even for users that are developers, few of them have the time to futz with source code. If it takes them more than about 15-30 minutes to get something up and running, they will move on to something else. I think that, to a degree, the same is true of at least some of the TigerVNC users. I don't think we can assume that our users are all developers or have access to the kinds of tools necessary to build this code. That being said, as Pierre points out, in the long term some of the burden of packaging will be taken up by Linux distributors. I still think there is a lot of value in shipping a generic RPM and DEB package, and I definitely think we need to ship Windows and Mac client binaries regardless. It may be common to ship only source, but I guarantee you that if you look at the most popular projects on SourceForge, they all ship binaries. I know a lot about packaging, so I'll volunteer to do the work of packaging TigerVNC -- just not immediately. :) I think that we probably want to have an RPM spec file for 1.0.0, but other packaging is something I would want to look at down the road as the performance gets good enough that I can start looking at replacing TurboVNC. Then, I would want to get TigerVNC into my nightly build system so I can auto-generate a .deb, .rpm, .dmg, and .exe for it each night. This is all advanced work, though, and definitely not something that I'd be able to do within the next couple of months. Pierre Ossman wrote: >> One important question is whether we - the TigerVNC project - should >> distribute binaries. I think it's more common, and easier, to not doing >> that; only distribute source. But as I understand it, TurboVNC distributes >> binaries, and perhaps that's something that TurboVNC users really wants. >> DRC, what's your opinion? >> >> > > Long term I agree, but short term we might want to make binaries > available so that tiger can be used on distributions where it hasn't > been included yet. > > Or do we consider it easy enough to build now that we have this script? > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
