I've been chatting with Kim this morning about sugar project hosting... I have several goals here:
o something that OLPC can be comfortable depending on (we have currently the strongest dependency on Sugar and put in the most developer resources; this is unlikely to change in the immediate future). Reaching this comfort-level is essential, in my view, toward any successful migration. Today, if we screw up, we screw up and take the biggest hit; to take an external dependency for something as central to OLPC as sugar more than hand waving is essential; concrete plans and people are needed. o disentangling Sugar from operational OLPC services; for example, our developer/activation key distribution facilities are critical operational resources for OLPC. The current organic growth of the systems at OLPC means that we have had to be overly restrictive to access to machine(s) providing community services. This was driven home to me by the extended effort required to integrate Pootle with Git, and having these community services conflated with OLPC operational services being on the same physical systems caused what should have been a straightforward integration problem to become a month long headache. Making a Sugar separation would make our job cleaning up OLPC's system management easier, so we have some incentive to see sugar become administered independently. o enabling the system to be managed independently of OLPC, in particular our operational infrastructure; we are still inadequately staffed to "just do it" trivially, and I don't want promises made that cannot be kept. I also don't want to see future holdups such as happened with Pootle to repeat, as additional services useful to the Sugar project may become needed. Sugar as a project needs to be able to fill its own needs without getting entangled in situations that often come up in an project such as OLPC that now has operational pressures from deployment. And so long as Sugar is entangled with our operational infrastructure, Sugar makes OLPC's system management more difficult. o ensure (at least read-only) mirroring of key information (e.g. wiki, git tree, trac databases etc.) is easily possible, both for redundancy's sake, and for in-country use. There are a number of other related project sites which can/should be used to mirror this way (e.g. freedesktop.org), and countries need to be able to mirror sugar in country. Requirements/possibilities: 1) I think we can likely arrange to host a machine in the MIT co-lo center. It has lots of bandwidth. (last I knew, 5 different long haul carriers @ 1gig/second each touched down there; along with 10 gig up the river to Harvard, BU, etc.). There is precedent for even fully independent open source projects being in the co-lo center (e.g. X.org), that have had ties to MIT. 2) said machine must be fully remotely manageable (the MIT co-lo center has remote hands service if needed, along with professional backup services). 3AM weekend phone calls are for the birds. 3) OLPC might be able to pay for a machine for Sugar, though this isn't a slam dunk or guaranteed. See 4) 4) someone needs to specify exactly what said machine will be (e.g. memory, disk, CPU, dual power supplies, etc.); once I know that, I can see if OLPC might be able to pay for it, if need be, but hand waving doesn't help here. I don't have time to do this research right now. 5) a concrete plan as to how to establish any source repositories from the community web services (which are typically the least secure parts of the services); some virtualization technology is sufficient for this separation, I believe, to start. I still have scars on my back from the freedesktop.org break-in, where it took us 6 weeks (IIRC) to re-verify each and every line of code in that system's project repositories against personal copies people had made. This is essential to enable less paranoia about access for people doing system administration of the web services part of a hosting system. 6) someone to write in blood that said system will be properly backed up (and that backup be tested), and mirrored elsewhere. Freedesktop (Portland) is one option, develer another (Italy) for initial mirroring. A sysadmin team needs to be formed so there is no single point of failure and timely response to issues. 7) I can do the physical installation of said system, if necessary, and get a remote console on the network with your favorite installation DVD installed. But a plan from there needs to be formulated... I'd like to see a credible plan about how said system's software will be installed, by whom, with a sketch of the software configuration. We'd also need a plan for migration of sugar specific activity would take place, without disturbing the current development stream any more than necessary. Acknowledgment of the realities of release schedules is also needed in such plans... And if it feels I'm holding this to a higher standard than the current situation, you are right: we need Sugar to become a more professional project as its user base is growing at a huge rate. We have to see progress in a forward direction to be worth the effort to change. I think that it could be/should be in everyone's benefit to do so. Comments? - Jim -- Jim Gettys <[EMAIL PROTECTED]> One Laptop Per Child _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar