I think even fyodor could easily handle the load of the wm project, however I agree that you should present it to them and have them join straight to our new setup, which will hopefully be ready by the time they are. I think that if we keep on track and don't get bogged down with minutiae and alternatives, we can be up and running on a new host within 45 days. I think we should set that as a goal and set some timelines for buying the new server, getting Abu offline, moving into a new cabinet etc. In particular I think we should set a goal of "moving into new cabinet" for 30 days from now. And I think now would be a good time to schedule our next meeting if possible, and have our hardware vendor and colo provider settled on and ready to order at that time.
Right now I'm going to go out on a limb and say we are leaning heavily towards Peer1/Penguin Computing, with possible alternatives of HE.net/Dell. I think we should not be entertaining any new vendors or networks that we have not previously considered at this point in time. -ntk Adam Chlipala wrote: > Andre Kuehne wrote: > >> I am a bit involved in the wm-dev mailinglist and know from there that >> the window maker maintainers are looking for a new hosting solution. >> >> I thought about suggesting hcoop to them, but i have no clue if we are >> up to the task at the moment, or in general, or if there might be other >> issues i didn't thought about. >> >> Besides the standard requirements they moved their development tree >> > >from CVS to darcs. I am no darcs expert, but as far as i know about > >> darcs and our hosting architecture, setting up a remotely commmitable >> darcs repo would require either >> >> - an own unix user for the repository and then storing public keys of >> all commiters into ~repo-user/.ssh/authorized_keys >> >> - or using some kind of server process or cronjob which applies >> patches send via email >> > I'm not familiar enough with darcs to say. Basically, anything that can > be done safely in a shared environment of mutually-untrusting users > without imposing a large hardware resource or administrative burden > should be doable. > > It would probably be a shame for them to join before we switch to our > new server architecture, though, since it would mean re-doing their > configuration at most a few months later. There are also the > reliability concerns about our current architecture that I've voiced > many times before, such that I wouldn't recommend that such a > high-profile project sign up with us yet. > > _______________________________________________ > HCoop-Discuss mailing list > [email protected] > http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-discuss > _______________________________________________ HCoop-Discuss mailing list [email protected] http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-discuss
