[sugar] Autonomous system for Sugar development....

[Walter Bender]

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 <jg at laptop.org> 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 <jg at laptop.org>
> One Laptop Per Child
>
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>