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

[Jim Gettys]

Assurances are one thing: concrete plans for execution are another....

Let's get concrete...
                      - Jim


On Thu, 2008-06-05 at 12:22 -0400, Walter Bender wrote:
> 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
> >
-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child