Ah, all right... Understandable. Then the question is still up to systems@ whether there is some willingness to set up a machine/vhost, or we will better do with opening a vhost on some new donated machine offered by a docteam member?
The added benefit of the latter option would be that we will not be reliant on the systems@ group for configuration changes, but the site could still be registered as doc.php.net, and we can be more flexible with its development and setup... The more I think about it, the more I like this option :)
I don't. You want this to be an official PHP thing, then it should be hosted on an official machine. We can't have each subproject being run by somebody else (if only for security reasons).
That server would only need to cvs checkout data anonymously, and it should be reproduceable on any other machine with the contents stored in cvs.php.net (the modules I have mentioned before, plus the new docweb module, plus a lot of generated data produced by the scripts from the sources anonymously checked out). Since it would only host data already publicly available (though in a more organized form), I don't know what is the problem with it...
Some PHP.net subdomains already hosted on 'foreign' servers:
- wiki.gtk.php.net - vancouver.php.net - sydney.ug.php.net - every PHP.net mirror site
The PHP.net mirror sites are considered to be 'official' as far as I can see, and they seem to be harder to control then doc.php.net would be on a non-systems@ operated machine. The operators of doc.php.net would be those who work closely with the docteam, so they are here to contact and act with if something need to be done.
It might be true however, that most of the members of the docteam are not experienced server operators (including myself), and you might think that it could be a prestige problem for php.net if someone breaks into the server and uses it for some crude goal... That could happen however with any of the above servers, since the administration skills of those operating the above servers have not been tested AFAIK. I would like to point once more that only data available from CVS, and data generated from those files with scripts available from CVS will be hosted on that machine (given that we are not going to have our own bugs reincarnation, which I take for granted for now, as I have stated before).
The actual problem with systems@ is that this group is 'not too responsive'. I have seen requests for cvs module and mailing list creations, and other stuff come and pass without any action taken... I have been asking for months that an 'has_sqlite' column should be added to the mirror registration table, but noone cares to add it... It would be hard to prove that it would be a complicated task to add this column... Still, my repeated requests were dismissed without an answer. I hardly beleive that you don't understand why we would not like to put a new vhost on the shoulders of [EMAIL PROTECTED]
In an ideal world, people at systems@ would be responsive, and would do what you ask them, or reply with a letter that you are asking for something silly or too complex. I can understand that everyone has his own work, and this is a volunteer task, everybody is volunteering here. Still I think that it is wrong not to admit that there are problems with the processes going through systems@, and that it often takes very long time to make any change... So while respecting the work done by the guys at systems@, to rapidly develop this new site, the slow pace of systems@ does not seem to be supportive...
Goba
