Hello Daniel, Ah, we are getting somewhere... :)
On 7. Aug 2010, at 11:50, Daniel Pfeifer wrote: >> 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. Yes, but for user interaction I'ld like to have them together, which means they have to be migrated to the new service eventually. In the upcoming weeks I'll look into github to see if it provides what we need. > 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?) No, not as much as I'ld like. > >> 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... True - hence my statement that we'll switch, but just not *now*. > >>> 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. One step at a time. Right now I'm importing the svn repo to github, and will set up the automatic sync. What's the issue with the backmerge? Loosing the committer id? > >> 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 ;-) It's not generated content on Windows. ;) > > What does Windows lack? Something that can not be solved by CMake? Maybe, but would require the developers to install the additional tools. My philosophy is that Equalizer should be easy to set up and compile, in order to lower the entry barrier. I *hate* when I'm downloading some OSS to hunt dependencies for hours just to get it to compile, usually I just drop the stuff if it takes more than 30 minutes. Right now we have a small perl script to convert the .glsl into an includable header, and links/lynx to generate the RELNOTES from the html source. I guess for the former there are easy alternatives, and for the latter it doesn't matter much. I'm open for ideas. :) >> 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. You can always ask, and we can take it offline if you want. :) What's the benefit of QuickBook? On a quick glance it seems to me that it would be a better fit for the 'website' files. >> 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? No strong reason. Afaik the only files are: agl/wgl/glx*.h defines<OS>.h The former can (and should be installed) on all OS's, the latter are at least partly generated atm and would need to be *cough* checked in. In fact, one does only need them if he has compiled on these platforms. >>> 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!). I'ld love that, but don't have the time to do so. >> 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. It's 10Megs: -rw-r--r-- 1 eile eile 9.8M 2010-02-05 14:39 Equalizer-0.9.1.tar.gz -rw-r--r-- 1 eile eile 9.8M 2009-08-11 10:11 Equalizer-0.9.tar.gz > > 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. I see. What about: 1) Reducing the size of the existing test images so that the tests always run 2) Provide an additional, extended test set for 'power users' and plugin developers? Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
