Hi Daniel, Thanks for your input.
On Wed, Aug 4, 2010 at 6:56 PM, Daniel Pfeifer <[email protected]> wrote: > 1. Leave Sourceforge, join GitHub! I think we can all agree that sf is slow, and that git is faster than svn. There are two practical things to consider: 1) Sourceforge is more than source hosting. We use the tracker and download system a lot, for example. 2) Not everybody is comfortable with git When do you perceive the slowness of git-svn? I personally use it for over a year, and the only slow operations are git svn rebase and dcommit, which I do rarely. My feeling is that we will switch to git in due time, but for now keeping the svn repo is useful. > IMPORTANT: Using Git and Subversion in parallel and syncing between > the two is something we should avoid. The goal should be to simplify > collaboration and contribution, not to complicate maintenance!! Agreed - but I'll nevertheless will quickly look into it. I don't think it's a big deal to automate this, and you get a git repo now. Is this an option for you? > 2. Drop all Toolchains except CMake > ----------------------------------- > directories: make, VS2005, VS2008, XCode > all files named Makefile > > Or is something still missing in the CMake files that the other > toolchains support? Whatever you mentioned in README.CMake. Once it works, we can switch. > 3. There are generated files inside the source tree > --------------------------------------------------- > And some of them are even under version control. This clearly is an > error. All generated files should be placed in the build tree. > Generated files do not belong under version control. I respectfully disagree. They are only generated on Unix systems, since the environment on Windows is somewhat lacking. Some are only generated if certains tools are installed, e.g., src/RELNOTES. It makes sense to check them in. > 4. Drop unmaintained parts or maintain them! > -------------------------------------------- > some examples fail to compile (SharedData.h is not found). Ack. I found only eqNBody, which I missed previously. It's fixed now. Do you have other examples? > 5. Drop unfree parts or free them! > ---------------------------------- > The ProgrammingGuide's license does NOT comply with the Open Source > Initiative ("OSI")'s Open Source Definition. It is against the terms > of use of sourceforge to have it in their repository!! > Ref: https://sourceforge.net/apps/trac/sitelegal/wiki/Terms_of_Use No, it's not. Associated content does not need to be OSI-compliant. No offense, but do you really think that it is productive to pick on the fact that auxilary, extensive documentation available *for free*, compiled in my spare time, is not available under an OSI license? The alternative here is that we keep the Programming Guide in a private repo, which makes little difference for anybody, except that there is less documentation available (e.g. all the images for reuse). > 6. Reorganize header files > -------------------------- > current situation: > * all header files lie inside the source directories > * during configuration some header files get copied to another dir, > some headers get generated > * this directory is used as include directory during compilation > * files in this directory are used during installation/packaging > > disadvantages: > * needs additional maintanance in the toolchain > * when i change a file in the wrong directory, then run configure, > my changes are losts > * installed header files depend on the system. when i want to > crosscompile for windows under linux i cannot use the installed > headers. > > advantages: > * I cannot think of a singe one. Please enlighten me! The headers and source are in the same directory. There is little chance that you can change my mind on this one, since I don't like to store them apart. We can change the toolchain to mark the headers differently for installation, if you have a good proposal. Symlinks come to mind, but then there is Windows.... > 7. Automatic regession testing (AKA CI) > --------------------------------------- > Just do it. And provide results online. Like extending the existing tests? > But analyzing the size of 'src' reveals a much bigger problem: > Equalizer source code 3.5 MB > Example code and configs 4.5 MB > Toolchain files 2.0 MB > Dependencies for Windows 9.5 MB > Test data 85.8 MB > > SO much test data? Really? What's the issue? The big blobs are uncompressed .rgb files, which are compressed easily by git & ssh. Uncompressed it's still an order of magnitude less than all the stuff generated during build, so disk space should not be an argument as well. > What do you think? See above - please don't feel discouraged when I don't agree. On some matters there are different opinions, and while I appreciate yours (and will keep them in mind), sometimes I will overvote you due to other realities/feelings/priorities. ;) Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
