Hi Stefan, Am Donnerstag, den 05.08.2010, 14:09 +0200 schrieb Stefan Eilemann:
> 1) Sourceforge is more than source hosting. We use the tracker and > download system a lot, for example. Well, this is nothing sf specific, since every other source hosting platform (GitHub, Launchpad, CoogleCode...) provides these features too. You are not even limited to use a single platform for all features. You can host the code on GitHub, tracker on SourceForge, Ubuntu packages on Lauchpad... However, then you loose those small extras like 'closing an issue from a commit log entry' or 'automatic creation of downloads from tags'. (by the way, does sourceforge provide these features yet?) > 2) Not everybody is comfortable with git This is subject to change. In the past, not everybody was comfortable with svn. Some people even use cvs these days... > > 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? Absolutely. But how do you plan to sync the git->svn way? The other way round is rather easy. You will see that it really is a big deal. > 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. Wow. In my opinion it does never make sense to have generated content under version control, but opinions diverge ;-) What does Windows lack? Something that can not be solved by CMake? > 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? Probably not. But I wanted to port the documentation to quickbook (http://www.boost.org/doc/libs/1_43_0/doc/html/quickbook.html) in my spare time and make it available for free. Then I recognized that I am not allowed to do so. > 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. Fair enough. I agree that personal preference is important here. > 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.... Of course we can create forwarding headers instead of copies/symlinks. But still it would be nice if all public headers were installed on all platforms. Is there a reason not to do it? > > Automatic regession testing (AKA CI) > Like extending the existing tests? No, what I meant by 'automatic' is... well automatic! Like each time someone pushs code to the repository, the code is built, tests are run and the developer that pushed the code receives an email if something fails. Something like Hudson or better BuildBot (python!). > 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. I wanted to debianize Equalizer because libMaoni has Equalizer as a dependency. I cannot completely debianize libMaoni as long as Equalizer is neither in Ubuntu or in my PPA. It is not disk space, but the size of the source package. I am not going to upload 30Megs when 700K would be sufficient. Why not just drop unneeded parts from the source package? Because that is how debian works: The debianizer should not modify the original package, but take it unmodified from upstream and pair it with a diff. cheers, Daniel _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
