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

[Jim Gettys]

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