I assume we need to do the CVS2SVN conversion.
Can we import the existing mailing list?
We probably need a prominent 'download' page.
How much work is the Wiki conversion?
John.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We need to scp the cvsroot (which might not work, depends on sf shell access) and the data files of our wiki on sf (same caveat). With the cvsroot on the server, we just need to run cvs2svn which should be done in a couple of minutes.
Mailing list: Are you talking about the lists of our current subscribers? Again, this should only depend on sf. Can you get a hold of those lists? If yes, there should be no problem with that.
Which reminds me: do we want/need a way to browse the mails on the lists via the web? Since all we send out currently are announcements and commits, I don't think so.
Regards,
Manni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. Then I guess that all that is missing is the following:
* All developers need to send me a public ssh key to they can get access to the server and to the svn repository.
* Downloads: I need to get (at least) the files for the current version and make a little page that lists and links them.
* A deadline. When do we move? When do we block access to our cvs repository on sf and switch the wiki to read-only? As soon as we are sure that there will be no more commits to cvs, I can rsync the cvsroot and convert it.
Regards,
Manni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Deadline: I think we should get v1.0.1 out from SF and then migrate the repository. I'd be happy to see the Wiki go read-only before that, any reason not to do that now. So v1.0.1's date is critical... how about we target February 15?
John.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any reason why we shouldn't switch the domain ASAP? It's lot easier to test that way and the front page can always point to sf? Where is POPFile sending it's stats?
Manni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've already got a couple of keys from you guys. And it seems that part went just fine.
I decided to build a little download page in the wiki. I guess that'll do.
Here's something I don't want to decide on my own:
Our cvs repository contains four modules: engine, windows, mac and linux. The latter two seem to be pretty much dead. Should I import them to svn as well?
Manni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I need a little more information to get us up and running.
svn
I finally chose to setup svn to not use system users. People who are allowed to commit have their login names and passwords stored in a special file in the subversion directory. I think it would be best to keep our old logins (even if I can no longer stand my handle), but if you prefer to change yours just let me know. What I definitely need from all the developers is a password for svn access.
mail
Do you want an account on getpopfile.org or just a redirect somewhere else?
Guess that's all for now altough I'm sure that there's something I forgot.
Regards,
Manni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been pondering the question of which svn access method to use quite a lot. I finally decided against svn over ssh.
My first thought was that ssh would be the obvious choice. Everything is handled by keys, no need for stupid hard-to-maintain passwords, etc. On the other hand, ssh can lead to file-permission problems and there's no way to grant anonymous read-only access. Of course, there are work-arounds for those problems and I could offer svnserver AND ssh access.
I guess it all depends on what we want. So just give me your opinions.
Manni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not being able to commit without typing a password would be a downgrade from SF.net. I really like being able to commit using svn+ssh (which I do on my other projects) because I don't have to have the password to hand (or type it).
John.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
it's already been a while since I've set up a server that could be the new home of POPFile.
It's a machine running Debian. Most of the http stuff is covered by Apache, mod_python, and Trac.
I've also installed a mail server (Postfix) and an IMAP/POP3 server (cyrus). I guess the latter part might not be necessary.
Mailing lists are handled by minimalist.
Subversion will provide for our revision control.
I have also installed dokuwiki so that we can simply use a copy of our current wiki on the new machine.
You can test-drive the server at this url: http://h1212143.stratoserver.net/
Any missing software that we might need?
Regards,
Manni
I think this looks very nice.
What do we need to do to transfer over here?
I assume we need to do the CVS2SVN conversion.
Can we import the existing mailing list?
We probably need a prominent 'download' page.
How much work is the Wiki conversion?
John.
Hi John.
We need to scp the cvsroot (which might not work, depends on sf shell access) and the data files of our wiki on sf (same caveat). With the cvsroot on the server, we just need to run cvs2svn which should be done in a couple of minutes.
Mailing list: Are you talking about the lists of our current subscribers? Again, this should only depend on sf. Can you get a hold of those lists? If yes, there should be no problem with that.
Which reminds me: do we want/need a way to browse the mails on the lists via the web? Since all we send out currently are announcements and commits, I don't think so.
Regards,
Manni
We can get the raw CVS repository via rsync: https://sourceforge.net/docs/E04/#rsync
We can pull the subscriber list for each of the lists without a problem.
I don't think we need list browsing.
John.
OK. Then I guess that all that is missing is the following:
* All developers need to send me a public ssh key to they can get access to the server and to the svn repository.
* Downloads: I need to get (at least) the files for the current version and make a little page that lists and links them.
* A deadline. When do we move? When do we block access to our cvs repository on sf and switch the wiki to read-only? As soon as we are sure that there will be no more commits to cvs, I can rsync the cvsroot and convert it.
Regards,
Manni
OK, I've sent you my public key.
Downloads... you can just grab from here.
Deadline: I think we should get v1.0.1 out from SF and then migrate the repository. I'd be happy to see the Wiki go read-only before that, any reason not to do that now. So v1.0.1's date is critical... how about we target February 15?
John.
Sounds good to me.
Are you sure that you sent me that key? Haven't gotten anything yet.
Manni
I've just resent it.
John.
Any reason why we shouldn't switch the domain ASAP? It's lot easier to test that way and the front page can always point to sf? Where is POPFile sending it's stats?
Manni
Sounds good to me.
I have no objection. Since I control the DNS... what IP address do you want?
John.
85.214.59.241
Manni
Done.
Obviously will have to wait for DNS servers to update.
Can you change the favicon on the site to something other than the Trac default?
John.
Sure. I'll see if I can find Otto somewhere.
Manni
Manni,
Several documents on the new server seem to be older than SF.net's.
For example, http://getpopfile.org/docs/jp says that the current
POPFile version is v0.22.5, but I've updated the page on SF.net
on December, 21.
Please see:
http://popfile.sourceforge.net/wiki/?do=recent
Will you update the documents on the new server?
Or, we have to update them manually?
Naoki
Don't worry, Naoki. I just scp'd all the data from the sf dokuwiki installation to the new server and I'll soon have them online.
Regards,
Manni
Manni,
OK. Thanks.
Then, we should stop updating the documents on SF.net.
I'll announce it to the maintainers of Japanese documentation.
Naoki
Thank you.
For now, I have disabled editing on the old sf wiki.
Manni
Hi,
I've already got a couple of keys from you guys. And it seems that part went just fine.
I decided to build a little download page in the wiki. I guess that'll do.
Here's something I don't want to decide on my own:
Our cvs repository contains four modules: engine, windows, mac and linux. The latter two seem to be pretty much dead. Should I import them to svn as well?
Manni
My take is 'yes'. They may be dead, but there's no reason to throw away the history.
John.
Hi folks,
I need a little more information to get us up and running.
svn
I finally chose to setup svn to not use system users. People who are allowed to commit have their login names and passwords stored in a special file in the subversion directory. I think it would be best to keep our old logins (even if I can no longer stand my handle), but if you prefer to change yours just let me know. What I definitely need from all the developers is a password for svn access.
mail
Do you want an account on getpopfile.org or just a redirect somewhere else?
Guess that's all for now altough I'm sure that there's something I forgot.
Regards,
Manni
1. Just assign me a random password for svn access. I assume that we can do svn over ssh?
2. I'd prefer that jgc@getpopfile.org redirect to popfile@jgc.org
John.
Hi John,
I have been pondering the question of which svn access method to use quite a lot. I finally decided against svn over ssh.
My first thought was that ssh would be the obvious choice. Everything is handled by keys, no need for stupid hard-to-maintain passwords, etc. On the other hand, ssh can lead to file-permission problems and there's no way to grant anonymous read-only access. Of course, there are work-arounds for those problems and I could offer svnserver AND ssh access.
I guess it all depends on what we want. So just give me your opinions.
Manni
Not being able to commit without typing a password would be a downgrade from SF.net. I really like being able to commit using svn+ssh (which I do on my other projects) because I don't have to have the password to hand (or type it).
John.
OK. I've enabled ssh access.
Of course, this re-raises the question of logins. Should I give you a jgrahamc login?
Manni