[Alsaplayer-devel] alsaplayer.org and possible migration

[Dominique Michel]

As we was discussing before, we have to be sure at the alsaplayer website will
be working after the 03-May-2007 10:11:39 UTC. I just send a new mail to Andy
because alsaplayer.org is a well know url and it will be stupid to loose it.

Regarding a possible migration, I get a gmail account and I toke a look at
code.google. The fact is at, even if sourceforge is slower, at sourceforge
offer more as google, as example the compile farm that can be used to test a
software on different platform.

Another aspect of code.google I dislike is at a project is lost in a huge
amount of informations. Sourceforge interface is more in the spirit of linux,
simple but efficient. I personally prefer to have a host that provide good tools
for both the users and the programmers and nothing else, as to have to find my
way out a huge amount of non-useful documentations and gadgets.

I can be wrong, but if so, convince me.

Another fact is at sourceforge is extremely slow when downloading from
alsaplayer.org but is very fast when downloading from
http://sourceforge.net/project/showfiles.php?group_id=249

Maybe at we can combine the advantages of using the tools on sourceforge and
use code.google as faster code depository for the users. I am thinking here at
websites as http://www.gtkfiles.org/app.php/Alsaplayer or
http://freshmeat.net/projects/fftscope/?branch_id=28322&release_id=246999 using
direct links to the tarballs. An user that use those links will be redirected
on alsaplayer.org or on Andy's personal sourceforge directory for the old
releases or on my personal directory, and all are very slow.

BTW. is it some other websites as gtkfiles.org and freshmeat where we must
advertise Alsaplayer?  

As programmer, sourceforge shell is not so fast when doing a backup of something
big as the whole website, but I can do something else in the meantime. And ssh
is fast enough when committing a few files into the cvs and will not be faster
with svn.

It seem at both have pros and cons. cvs seem to be more flexible as svn, with
things as doing a tag. A tag will also take less space with cvs as svn. I can
be wrong, I am still learning both of them. I personally don't care which
system we are using in the future as long as it work and I can find my way
through, but I have more urgent think to do now as a cvs to svn migration.

But if someone want to do it and at the other peoples interested in the project
are also thinking at it will be a good thing, OK, just do it.

Ciao,
Dominique