[Sugar-devel] datastore situation (was Re: Hypothetical sugar-0.90 material, draft 1.)

[Tomeu Vizoso]

On Thu, Jun 10, 2010 at 17:48, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
>

I think this is an unfair recount of my work, so I'm going to put some
light on it and ask that my frankness is excused.

>  - Reworking the datastore... while I welcome efforts in a new
> datastore... _every Sugar release has a new DS implementation_

Not sure how you are counting, only 2 datastore implementations have
ever been released as part of a Sugar release (more details below).

> and
> they get little testing and I've seen extremely light thinking about
> what is _actually_ needed.

The first one was designed before Sugar had ever been in use, and
naturally suffered from the same big plans syndrome as most early-OLPC
software. This means that what got initially designed didn't matched
what turned out to be needed in the field, no big surprises here I
guess.

Another circumstance is that the person that was hired to work on that
implementation had his contract cancelled a few months after. He
started working at the end of April 2007 and his last commit is at the
end of October of that year: 6 months.

One more data point: OLPC never hired nobody else to work on the DS
since Ben's contract was cancelled. I tried hard to understand why,
asked my managers, but never got a response. I'm still puzzled at why
a so critical component was left in the prototype stage.

My responsibilities at OLPC included the Journal, which is totally
dependent on the DataStore for all its functionality. Given that the
DS was orphaned, I had to patch it as I went so the Journal
implementation could go on. I don't think it's fair to think that I
should have been able to take the DS from the prototype stage and make
it production-ready in my free time, and I certainly wasn't appointed
responsible for the DS by the OLPC management. That job position
remained vacant forever (same as the performance position).

In the following months, because of my role as Journal maintainer I
had plenty of opportunities to reflect on how that prototype failed to
meet the needs of users in the field and I tried hard to find a way to
do better with the resources that were available (almost zero).

This proposal went out in May 2008:
http://lists.laptop.org/pipermail/devel/2008-May/013716.html . In
summary, the main goal was reducing the frequency with which users
lost data while retaining as much functionality as possible.

With the feedback I got (including yours) a replacement was developed
and that's the implementation that was first released as part of Sugar
0.84.

Other people have designed and even implemented prototypes of other
alternatives to the DS, but nobody else than me happened to take the
responsibility of putting it into a product. What should I have done
instead, limit myself to publish papers and give talks about my
prototype and just re-release the old implementation in every Sugar
release?

> We need _a good, polished DS that covers
> many aspects sanely_... a new DS is unlikely to do so. IOWs the
> barrier to merge a new DS should be high. It just triggers my CADT
> alarms http://www.jwz.org/doc/cadt.html

Not sure how we can agree on rewriting or not rewriting if we haven't
agreed yet on what features should have the future releases of the DS?

Regards,

Tomeu

> Hopefully your list is not prioritised ;-) and it's just an accident
> that those two are top-of-the-list...
>
> Or maybe there's a goal to have 0.90 be a "break lots of toys towards
> a 'developer release' and then make 1.0 the real deal".
>
>
> m
> --
>  martin.langhoff at gmail.com
>  martin at laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>