Rest assured that Sugar Labs has every intention of being "professional" and upholding the highest standards of quality and conduct.
-walter On Thu, Jun 5, 2008 at 12:18 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: > 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 > [email protected] > http://lists.laptop.org/listinfo/sugar > _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
