On Thu, 2007-04-01 at 17:32 +0100, Michael Holzt wrote: > > Unless and until Michael decides that he no longer wants to host the > > wiki, I think he has the final word. > > No. While i "own" qpsmtpd.org and run the current wiki, my opinion is in > no way superiour than those of others. If the project (as represented by
Ok. > us all) feels that a twiki would help it and someone is willing to host > one, i'm ready to pass the baton. If the project wants me to continue > hosting the wiki, thats fine as well, but twiki is a no-no for me. But > in the end the decision is up to you. I don't think this is inconsistent with what I said. You have now confirmed your decision to not host the wiki if it must be twiki and if that is the case then I am willing to try to pick it up. I will keep your opinions in mind while I evaluate it. I will also look at some of the other packages suggested. In my mind the least disruptive option, including all the suggestions, as I understand them, would be to make some minor patches to docuwiki, link it to a trac instance, which would include a svn repo for contributed plugins and some additional functionality along the lines of vBulleting-webboard. If the result is something you are comfortable hosting and it is good enough, then fine. I think it is incumbent on the list to actually use the wiki more before too much effort goes into improving it. It'll probably take me a week to look at everything that's been discussed (I do have other things i need to do) more like two weeks to set up something new. We can always use 'twiki.qpsmptd.org' to let people compare before making a final decision. > > > I may be in a position to host the wiki before the end of February and > > I'd like to experiment with mirroring the content from Michael's server > > if that's ok with him. > > No objections. The machine is on a plan with all traffic included. If you > need help by me, please let me know. I'll try wget but it tends to grab all sorts of crap I don't want ... http isn't really designed for recursive mirroring. If there is shell access, I can send you a public key for ssh. Wget works ok over anon ftp ... but 'mirror' is nicer. I can use rsync ... but not bittorrent (overkill anyway for this). > > > Debian has very strict security guidlines and I expect that the Etch > > package will address most technical[*] concerns. > > But debian does not do a code audit. Based on the occurances in the past > i believe that the code base might not be overly clean and probably not I've looked at the code and I have nothing to say on that ;-) > written with security in mind. So there might be other security holes > hidden. I'm more worried that the radical ultra-pure faction (the ones for whom GFDL is a problem) might take over the project ... > > There is a saying in german "Wer einmal lügt, dem glaubt man nicht" (about: > we don't trust people caught lying once). Its some kind of the same > story here. The fact that some class of bugs with should haven't been > there in the first time (as said, the risk of user input is nothing new) > has been found multiple times combined with the attitude shown against > us brought me to my decision. But i'm not you, so you are free to decide > otherwise. ... debian is good enough for me. I just watch the elections every March to see if the new project leader seems reasonable. I'm prepared to switch to CentOS, OpenBSD or Solaris if necessary (in that order). > > > Regards > Michael -- --gh
