User:Mstone/Commentaries/Releases 1: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (New page: == Initial Unhappiness == m_stone> I take it that you guys are concerned that you'll have sugar in a releasable state say around mid-June or early July? m_stone> and that y...)
 
mNo edit summary
Line 2: Line 2:


m_stone> I take it that you guys are concerned that you'll have sugar in a
m_stone> I take it that you guys are concerned that you'll have sugar in a
releasable state say around mid-June or early July?
releasable state say around mid-June or early July? and that you'll
m_stone> and that you'll be unable to make big changes for the remainder of
be unable to make big changes for the remainder of the 1-1.5 months
the 1-1.5 months until the release?
until the release?
tomeu> well, I think the issue is not releasing something like last releases
tomeu> well, I think the issue is not releasing something like last
tomeu> some thing that more or less works
releases; some thing that more or less works but having a better API
tomeu> but having a better API and based on components that are more
and based on components that are more predictable
predictable
tomeu> "something that more or less works" == "something that passes the
tomeu> "something that more or less works" == "something that passes the
minimal QA work that has been done but that shows critical problems
minimal QA work that has been done but that shows critical problems
after being deployed"
after being deployed" - we are not happy how new features have been
tomeu> we are not happy how new features have been rolled out
rolled out






m_stone> tomeu: keep explaining, please. I really want to understand what
m_stone> tomeu: keep explaining, please. I really want to understand what
things look like from your vantage point.
things look like from your vantage point. (incidentally, that sounds
m_stone> tomeu: (incidentally, that sounds more like a QA failure rather than
more like a QA failure rather than a software team failure to me.)
a software team failure to me.)






tomeu> m_stone: building on an orphaned component like the DS is not very
tomeu> m_stone: building on an orphaned component like the DS is not very
nice, either
nice, either. well, project issues that needs to be solved - we
cannot blame QA because it has been composed by interns
tomeu> well, project issues that needs to be solved
tomeu> we cannot blame QA because it has been composed by interns
cjb> and is currently composed of no-one :)
cjb> and is currently composed of no-one :)
tomeu> we already complained last summer about interns leaving just when
tomeu> we already complained last summer about interns leaving just when
they started being useful
they started being useful. Also, I'm not happy with the parts of the
sugar API that I have contributed most, either






tomeu> I'm not happy with the parts of the sugar API that I have contributed
most, either



m_stone> tomeu: but help me understand how this affects the work you think we
should undertake to do for August 1 or the next release beyond.




Line 45: Line 36:
== Present Unhappiness ==
== Present Unhappiness ==


m_stone> tomeu: help me understand how this affects the work you think we
should undertake to do for August 1 or the next release beyond.
tomeu> m_stone: we want to have a software architecture more resilient to
tomeu> m_stone: we want to have a software architecture more resilient to
bugs, more maintainable, and want to give activity authors a better
bugs, more maintainable, and want to give activity authors a better
API. nothing of that are new features from the POV of the project
API
manager, I think. just dedicate time to it ;). Then discuss, discuss,
tomeu> m_stone: nothing of that are new features from the POV of the project
manager, I think
discuss, then implement, deploy.
tomeu> m_stone: just dedicate time to it ;)
tomeu> discuss, discuss, discuss,
tomeu> then implement, deploy






tomeu> so well, we have a problem deciding on what to spend time
tomeu> so well, we have a problem deciding on what to spend time - every few
tomeu> every few months we are promised a new DS
months we are promised a new DS. the activity API depends on that so
tomeu> the activity API depends on that
it's not evolving and really sucks because depends on important
implementation things like storing entries with delta compression. so
tomeu> so it's not evolving and really sucks
well, we would like to better plan things, and spend effort in
tomeu> because depends on important implementation things like storing
entries with delta compression
tomeu> so well, we would like to better plan things, and spend effort in
invisible features
invisible features


Line 68: Line 56:


m_stone> tomeu: cscott, cjb, and I spent several minutes yesterday debating
m_stone> tomeu: cscott, cjb, and I spent several minutes yesterday debating
whether cscott should try to fix networking things or DS things.
whether cscott should try to fix networking things or DS things. (and
m_stone> (and consequently whether cjb should fix networking things or power
consequently whether cjb should fix networking things or power
things)
things). (and whether the kernel folks should fix power things or
???). (and whether I should concentrate on collaboration or
m_stone> (and whether the kernel folks should fix power things or ???)
stability/compatibility things). we have two plans and we haven't
m_stone> (and whether I should concentrate on collaboration or
figured out yet which one is better.
stability/compatibility things)
m_stone> tomeu: we have two plans and we haven't figured out yet which one is
better.






tomeu> m_stone: right, that's also our problem
tomeu> m_stone: right, that's also our problem. I was supposed to work in
tomeu> m_stone: I was supposed to work in the journal. but had to choose
the journal. but had to choose between sugar, read, browse, ds, etc.
between sugar, read, browse, ds, etc. at different points
at different points and performance
tomeu> and performance




Line 89: Line 74:


m_stone> marcopg_: plan a) is cscott, cjb, & kernel folks on networking,
m_stone> marcopg_: plan a) is cscott, cjb, & kernel folks on networking,
mstone & collabora on collaboration, and sugar on ???
mstone & collabora on collaboration, and sugar on ??? where ??? is
m_stone> where ??? is probably the as yet unspecified "UI features that are
probably the as yet unspecified "UI features that are already in the
already in the bag + any accessible stability"
bag + any accessible stability". the other plan is cscott on DS, cjb
m_stone> the other plan is cscott on DS, cjb on limited cases of power, kernel
on limited cases of power, kernel folks on power, mstone on ???, and
folks on power, mstone on ???, and sugar on ???
sugar on ??? where ??? is the same as above.
cjb> I think there's a third plan of cscott, mstone and collabora on
networking, cjb and kernel on power, sugar on ???.
marcopg_> I'm not sure I understand why we are going through the two extremes
marcopg_> I'm not sure I understand why we are going through the two extremes
about networking
about networking
m_stone> where I think ??? is the same as above.
cjb> I think there's a third plan of cscott, mstone and collabora on
networking, cjb and kernel on power, sugar on ???.



marcopg_> we certainly need someone on it, but I doubt putting the whole team
marcopg_> we certainly need someone on it, but I doubt putting the whole team
on it will help
on it will help
Line 108: Line 89:


m_stone> I'll try to answer marcopg's question and I'll try to explain the
m_stone> I'll try to answer marcopg's question and I'll try to explain the
other flaws here.
other flaws here. first flaw: someone has to manage the release. at
m_stone> first flaw: someone has to manage the release. at present, I'm the
present, I'm the default candidate (though feel free to suggest
default candidate (though feel free to suggest others)
others). that's not immediately a full time job. but it will turn
into one and we can't forget it. also, effort will need to shift in
m_stone> that's not immediately a full time job.
the second half of the cycle toward making it happen. i.e. the
m_stone> but it will turn into one and we can't forget it. also, effort will
need to shift in the second half of the cycle toward making it
release manager will need to impose on erikos, or cjb, or... :)
happen.
m_stone> i.e. I will need to impose on erikos, or cjb, or... :)
m_stone> (rather, whoever the release manager is will need to do so)






m_stone> second problem:
m_stone> second problem: there is lots of debate about how many people can
m_stone> there is lots of debate about how many people can profitably work on
profitably work on networking, on power, on collaboration, on UI, on
networking, on power, on collaboration, on UI, on "stability", or on
"stability", or on "compatibility". in part, debate exists because
there are different approaches to each of these problems.
"compatibility"
m_stone> in part, debate exists because there are different approaches to each
of these problems.




Line 131: Line 107:
=== Power Management ===
=== Power Management ===


m_stone> i.e. one way to do power is to make it work in limited circumstances
m_stone> i.e. one way to do power is to make it work in limited circumstances.
m_stone> I think of this as the "low-hanging fruit" approach
I think of this as the "low-hanging fruit" approach. It mainly
m_stone> that mainly requires cjb + some kernel, we think.
requires cjb + some kernel, we think.
marcopg_> some kernel == not full time kernel person?
marcopg_> some kernel == not full time kernel person?
cjb> Yeah. I'd be surprised if we can't come up with an acceptable
cjb> Yeah. I'd be surprised if we can't come up with an acceptable
limited/incremental use of power that takes less than a day to
limited/incremental use of power that takes less than a day to
implement. I'll try to write something about this.
implement. I'll try to write something about this. For example, we
cjb> For example, we don't do power management if you're currently
don't do power management if you're currently connected to a jabber
connected to a jabber server, else we do.
server, else we do.




Line 146: Line 122:
comprehend the networking stack (so that we know what timeouts &
comprehend the networking stack (so that we know what timeouts &
wakeups are needed), to fix the kernel to make those timeouts &
wakeups are needed), to fix the kernel to make those timeouts &
wakeups occur, then to do more userland power management
wakeups occur, then to do more userland power management. similarly
m_stone> similarly for networking.
for networking.
cjb> (There are still the timeouts. It's hard to know how to tackle them,
when no particular misbehavior has ever been reported due to them.)




Line 153: Line 131:
=== Networking ===
=== Networking ===


morgs> Are the approaches mutually exclusive from a resource point of view?
cjb> (There are still the timeouts. It's hard to know how to tackle them,
when no particular misbehavior has ever been reported due to them.)
m_stone> one way to approach networking is to write down a believable
m_stone> one way to approach networking is to write down a believable
networking architecture, then to follow through.
networking architecture, then to follow through. (where a believable
m_stone> (where a believable networking architecture would contain a small
networking architecture would contain a small number of protocols
number of protocols that "stretch" to cover all of our present use
that "stretch" to cover all of our present use cases). the other way
is to try to follow the critical path toward one use case (e.g.
cases)
reliable read sharing on a school server wifi with K/N laptops) and
m_stone> the other way is to try to follow the critical path toward one use
case (e.g. reliable read sharing on a school server wifi with K/N
to fix every damn bug you find along the way until it works or until
you recognize defeat. the latter might get you a single working use
laptops)
case (or maybe 3), but it's not going to get you reliability,
m_stone> and to fix every damn bug you find along the way until it works or
stability, or leverage. (they also take different amounts of time)
until you recognize defeat
m_stone> the latter might get you a single working use case (or maybe 3), but
it's not going to get you reliability, stability, or leverage
m_stone> (they also take different amounts of time)




Line 174: Line 146:
=== Focus or Divide and Conquer? ===
=== Focus or Divide and Conquer? ===


morgs> Are the approaches mutually exclusive from a resource point of view?
cjb> morgs: my third approach does a fairly even split of three groups
cjb> morgs: my third approach does a fairly even split of three groups
into three things
into three things. we can argue that this *sort* of approach has been
cjb> morgs: we can argue that this *sort* of approach has been the main
the main problem with OLPC software development and has led to power
management that doesn't really work, a mesh that doesn't really work,
problem with OLPC software development
cjb> and has led to power management that doesn't really work, a mesh that
collaboration that doesn't really work, and a datastore that doesn't
doesn't really work, collaboration that doesn't really work, and a
really work.
datastore that doesn't really work.
m_stone> and, as cjb alluded, we presently feel like we have N demos rather
m_stone> and, as cjb alluded, we presently feel like we have N demos rather
than 1 solid product.
than 1 solid product. some people believe this is because we sent N
m_stone> some people believe this is because we sent N people in N+2
people in N+2 directions rather than either sending 10N people in N+2
directions
directions or sending N people in, say, 3 directions
m_stone> rather than either sending 10N people in N+2 directions or sending N
people in, say, 3 directions






marcopg_> I don't that's matter of people
marcopg_> I don't think that's matter of people; it's matter of too many
ambitious goals
marcopg_> don't think
marcopg_> it's matter of too many ambitious goals






tomeu> I don't think that having twice the number of people would have been
tomeu> I don't think that having twice the number of people would have been
a waste of resources
a waste of resources - in many projects it is, but in our case...
tomeu> in many projects it is, but in our case...
m_stone> marcopg_: the complete absence of a QA team definitely made itself
m_stone> marcopg_: the complete absence of a QA team definitely made itself
felt here...
felt here... (and the absence of software attacking the QA problem,
m_stone> (and the absence of software attacking the QA problem, e.g. test
e.g. test suites)
suites)
tomeu> the absence of a DS maintainer, too
tomeu> the absence of a DS maintainer, too






tomeu> the problem is that it depends on what we aim to do
tomeu> the problem is that it depends on what we aim to do and, regarding
tomeu> and regarding sugar, we just don't know right now...
sugar, we just don't know right now... perhaps later today
tomeu> perhaps later today






marcopg_> let me rephrase
marcopg_> let me rephrase: I don't think moving everyone to work on the network
will help the network a lot, at least on 4 months schedule. gradually
marcopg_> I don't think moving everyone to work on the network will help the
adding people to the current team would be much more sensible, ihmo
network a lot
marcopg_> at least on 4 months schedule
marcopg_> gradually adding people to the current team would be much more
sensible, ihmo




Line 227: Line 190:
useful
useful
m_stone> marcopg_: b) why, precisely, do you anticipate that (a) would fail?
m_stone> marcopg_: b) why, precisely, do you anticipate that (a) would fail?
m_stone> (or would be too expensive to pursue?)
(or would be too expensive to pursue?)






marcopg_> because it takes time for people to figure out how to work together
marcopg_> because it takes time for people to figure out how to work together
in a productive way
in a productive way. if we have uncovered areas then we should cover
them. which aspects of networking we are not covering right now?
marcopg_> if we have uncovered areas then we should cover them




Line 239: Line 202:
tomeu> m_stone: do you think that many of our orphaned or under-resourced
tomeu> m_stone: do you think that many of our orphaned or under-resourced
areas can only be tackled efficiently for people already in the team?
areas can only be tackled efficiently for people already in the team?
(in this case, without wasting most of the new resources' potential)
m_stone> depends what you mean by "efficiently"
m_stone> specifically:
m_stone> depends what you mean by "efficiently"; specifically: I think that we
m_stone> I think that we have individuals who have the experience required to
have individuals who have the experience required to 'begin labor' on
'begin labor' on many areas.
many areas but I don't feel that they'll have the ability to close
noticeable numbers of bugs
m_stone> but I don't feel that they'll have the ability to close noticeable
numbers of bugs






tomeu> m_stone: in this case, without wasting most of the new resources'
potential
tomeu> if we talk about how to distribute resources, we need to characterize
tomeu> if we talk about how to distribute resources, we need to characterize
every area as in how high is the entry point
every area as in how high is the entry point. some areas will require
tomeu> m_stone: some areas will require a longer effort to start being
a longer effort to start being productive, some less
productive, some less



marcopg_> m_stone: which aspects of networking we are not covering right now?




Line 267: Line 222:
Sugar over the next serveral months, whether that means putting all
Sugar over the next serveral months, whether that means putting all
or most of your human resources towards that. W/ the
or most of your human resources towards that. W/ the
datastore/Journal being most important.
datastore/Journal being most important. the networking and power work
BryanWB> the networking and power work well enough but it is fairly difficult
well enough but it is fairly difficult to use the Journal to find
to use the Journal to find stuff. Also, in my week's worth of QA,
stuff. Also, in my week's worth of QA, Sugar just does unexpected
stuff. Over the last 2 weeks of working w/ os699, then 702, now 703,
Sugar just does unexpected stuff
I have had the most problems w/ the Journal/datastore then Sugar
BryanWB> Over the last 2 weeks of working w/ os699, then 702, now 703. I have
had the most problems w/ the Journal/datastore then Sugar weirdness
weirdness.
marcopg_> I tend to agree with BryanWB, simply because the Journal is more a
marcopg_> I tend to agree with BryanWB, simply because the Journal is more a
base/fundamental use case then network sharing
base/fundamental use case then network sharing; i.e. losing your work
marcopg_> i.e. losing your work is more critical then not being able to share
is more critical then not being able to share an activity
an activity




Line 283: Line 237:
ample power, have a wireless AP and only one XO, of course you're
ample power, have a wireless AP and only one XO, of course you're
going to say that networking and power work fine. :)
going to say that networking and power work fine. :)
BryanWB> cjp: we are using an AP not active antenna
BryanWB> cjb: we are using an AP not active antenna
cjb> BryanWB: Yes. That's why I say it's natural that you would think it
cjb> BryanWB: Yes. That's why I say it's natural that you would think it
works fine.
works fine. What *doesn't* work is the mesh (non-AP) layer.
m_stone> cjb: rather, our choice of protocols and implementations is
cjb> What *doesn't* work is the mesh (non-AP) layer.
incompatible with the mesh. (I speak relationally because I suspect
m_stone> (cjb: rather, our choice of protocols and implementations is
incompatible with the mesh)
that we are more likely to change the protocols & implementations
m_stone> cjb: I speak relationally because I suspect that we are more likely
than we are to change the firmware)
to change the protocols & implementations than we are to change the
firmware




Line 298: Line 250:
one school, AFAIK. mesh is less important than basic usability of
one school, AFAIK. mesh is less important than basic usability of
datastore
datastore
tomeu> BryanWB: I think peru's next deployments will use mainly mesh, but
I'm not sure
tomeu> BryanWB: that's another problem we have, knowing the very different
tomeu> BryanWB: that's another problem we have, knowing the very different
problems of every deployment location
problems of every deployment location. I think peru's next
deployments will use mainly mesh, but I'm not sure.
BryanWB> tomeu: they can buy a small AP and power backup for Peruvian schools.
BryanWB> tomeu: they can buy a small AP and power backup for Peruvian schools.
Power backup is pretty ubiquitous anywhere they have electricity and
Power backup is pretty ubiquitous anywhere they have electricity and
load-shedding. ** at least in south and east asia ** don't know
load-shedding. ** at least in south and east asia ** don't know
south america
south america
cjb> BryanWB: what about when the kids go home from school, though?






erikos> i think both are important use cases mesh and datastore and should
erikos> i think both are important use cases mesh and datastore and should
both be addressed
both be addressed - i hope that for august we can do both - at least
parts. we once started to provide mesh usability - and should
m_stone> erikos: sure, but in which order?
continue to push for it; i think the statement that the datastore
erikos> m_stone: well i hope that for august we can do both - at least parts
should work is out of question
erikos> m_stone: we once started to provide mesh usability - and should
cjb> the problem is that no-one is confident we can get there by pushing,
continue to push for it
rather than by throwing out what we have and redesigning. I guess
erikos> m_stone: i think datastore should work is out of question
then we come to a question of whether the datastore can also be made

to work properly incrementally.


=== Feedback from Peru? ===

m_stone> so two questions: 1) what have the peruvian teachers discovered about
703?
m_stone> carla was clearly upset about a mesh bug.
marcopg_> m_stone: that's something that the deployment team should figure out
marcopg_> m_stone: we just don't have enough information at the moment to say
it
m_stone> marcopg_: in which case the priority should be to get that
information, yes?
m_stone> or to change the decision so that it's no longer necessary.
marcopg_> m_stone: I think that should be the priority, yeah



cjb> BryanWB: what about when the kids go home from school, though?
cjb> erikos: the problem is that no-one is confident we can get there by
pushing, rather than by throwing out what we have and redesigning.
cjb> erikos: I guess then we come to a question of whether the datastore
can also be made to work properly incrementally.




Line 346: Line 277:
cjb> since cscott's time is one of the main variables here, and he'd be
cjb> since cscott's time is one of the main variables here, and he'd be
doing olpcfs.
doing olpcfs.
m_stone> cjb: well, we might be able to have two people work on it.
m_stone> cjb: well, we might be able to have two people work on it. for
m_stone> cjb: for example, one person could start implementing the testing!
example, one person could start implementing the testing!
marcopg_> cjb: that clashes with this "compatiiblity" requirement which has
been added for unknown (to us) reasons
erikos> cjb: sure - i mean if we feel we have to throw something out - we
erikos> cjb: sure - i mean if we feel we have to throw something out - we
might have to keep a beta solution in the hands as well
might have to keep a beta solution in the hands as well. in the case
erikos> cjb: in the case of the datastore - if we decide we rewrite (i think
of the datastore - if we decide we rewrite (i think that is what
that is what people feel) we should start now
people feel) we should start now



cjb> I think the short answer is that we shouldn't have to be making these
cjb> I think the short answer is that we shouldn't have to be making these
decisions ourselves. But if we write them up clearly enough, we can
decisions ourselves. But if we write them up clearly enough, we can
pass the decision up the chain.
pass the decision up the chain.
tomeu> having to choose between mesh and datastore is like choosing between
drinking or eating - both are needed






=== Feedback from Peru? ===
tomeu> having to choose between mesh and datastore is like choosing between

drinking or eating
m_stone> so two questions: 1) what have the peruvian teachers discovered about
tomeu> both are needed
703? carla was clearly upset about a mesh bug.
marcopg_> m_stone: that's something that the deployment team should figure out
- we just don't have enough information at the moment to say it
m_stone> marcopg_: in which case the priority should be to get that
information, yes? or to change the decision so that it's no longer
necessary.
marcopg_> m_stone: I think that should be the priority, yeah




Line 373: Line 308:
m_stone> marcopg_: you say the "compatibility" requirement is "unknown"?
m_stone> marcopg_: you say the "compatibility" requirement is "unknown"?
marcopg_> m_stone: I don't know why it has been suddenly added to the list of
marcopg_> m_stone: I don't know why it has been suddenly added to the list of
top reqs
top reqs. (I'm not against, I'd just like to understand better)
marcopg_> (I'm not against, I'd just like to understand better)






m_stone> marcopg_: first, let's make sure we mean the same thing.
m_stone> marcopg_: first, let's make sure we mean the same thing.
m_stone> compatibility means two things:
compatibility means two things: 1) our software running on other
m_stone> 1) our software running on other people's platforms
people's platforms and 2) other people's software running on our
m_stone> 2) other people's software running on our platform
platform.






m_stone> we mean both of these, I think.
m_stone> we mean both of these, I think.
marcopg_> but there are a lot of possible approaches
marcopg_> but there are a lot of possible approaches with pretty different end
results and that's the main reason I want to know why it was pushed -
marcopg_> with pretty different end results
to figure out solutions that meets the exact requirements
marcopg_> and that's the main reason I want to know why it was pushed
marcopg_> to figure out solutions that meets the exact requirements
bemasc> cscott specifically referred to #2, not #1
bemasc> cscott specifically referred to #2, not #1


Line 397: Line 330:


m_stone> agreed that the reasoning behind making it a priority has not been
m_stone> agreed that the reasoning behind making it a priority has not been
explained.
explained - I'll try to articulate the justification. 1) we wish more
people were supporting our platform. We thing that there are two ways
m_stone> I'll try to articulate the justification.
to do this - first, to bring our software to them, and second, to
m_stone> 1) we wish more people were supporting our platform. We thing that
there are two ways to do this - first, to bring our software to them,
give them an immediate userbase running on our platform and 2) we're
and second, to give them an immediate userbase running on our
concerned, from time to time, that the days of funded support for our
platform
platform are limited; therefore, we wish it to be less expensive to
maintain.
m_stone> 2) we're concerned, from time to time, that the days of funded
support for our platform are limited.
m_stone> therefore, we wish it to be less expensive to maintain.






marcopg_> how much limited?
marcopg_> how much limited? 1-2 years or 1-2 months? ;)
marcopg_> 1-2 years or 1-2 months? ;)
m_stone> marcopg_: we've been greatly reassured on this point in recent weeks.
m_stone> marcopg_: we've been greatly reassured on this point in recent weeks.
m_stone> marcopg_: (specifically by the fact that kim's budget was accepted)
(specifically by the fact that kim's budget was accepted). but I
m_stone> marcopg_: but I think that anxiety is a driving factor in the desire
think that anxiety is a driving factor in the desire to increase
to increase compatibility.
compatibility. as for your question: "both, with different
m_stone> marcopg_: as for your question: "both, with different liklihoods"
liklihoods"






tomeu> we are having to guess too much, considering we have kids using the
tomeu> we are having to guess too much, considering we have kids using the
laptops in the thousands
laptops in the thousands and adding anxiety to the guessing...
tomeu> and adding anxiety to the guessing...
m_stone> tomeu: I say the same thing all the time but I don't know what to do
m_stone> tomeu: I say the same thing all the time but I don't know what to do
about it.
about it. the anxiety has greatly abated. we are now confident enough
in survival to begin hiring.
m_stone> tomeu: the anxiety has greatly abated. we are now confident enough in
survival to begin hiring.




Line 432: Line 360:


marcopg_> m_stone: do we expect countries to actually deploy machines with
marcopg_> m_stone: do we expect countries to actually deploy machines with
standard applications installed?
standard applications installed? and are we going to encourage or
marcopg_> m_stone: and are we going to encourage or discourage it
discourage it?
marcopg_> the degree of compatibility we need is also an important factor for
marcopg_> the degree of compatibility we need is also an important factor for
the datastore work
the datastore work even though I think we will be forced to do
marcopg_> even though I think we will be forced to do *something* about the
*something* about the datastore situation by august
datastore situation by august



tomeu> m_stone: which legacy software needs to be run in the laptops and
tomeu> m_stone: which legacy software needs to be run in the laptops and
which problems it has?
which problems it has? if it's flash apps, then the compatibility
tomeu> if it's flash apps, then the compatibility stuff gains a totally
stuff gains a totally different meaning if it's java, we may have
different meaning
different problems than APIs
tomeu> if it's java, we may have different problems than APIs




Line 452: Line 375:
authoritative answers for.
authoritative answers for.
marcopg_> m_stone: ok, that's a question we need to answer I think
marcopg_> m_stone: ok, that's a question we need to answer I think
m_stone> no kidding.




Line 462: Line 384:
navigation tool pointing to local persistent data
navigation tool pointing to local persistent data
tomeu> from my pov, the same mechanisms that olpcfs has for that, could be
tomeu> from my pov, the same mechanisms that olpcfs has for that, could be
added on top of the current implementation
added on top of the current implementation. we could add a fuse
tomeu> m_stone: we could add a fuse thingy on top of the current DS
thingy on top of the current DS
m_stone> tomeu: I'm skeptical that the current DS would withstand that much
m_stone> tomeu: I'm skeptical that the current DS would withstand that much
stress...
stress...
Line 473: Line 395:


tomeu> we talk about compatibility, but do something because of performance
tomeu> we talk about compatibility, but do something because of performance
marcopg_> there is value in the idea of reusing the API though
marcopg_> there is value in the idea of reusing the API though and to start by
marcopg_> and to start by fixing the implementation
fixing the implementation
m_stone> marcopg_: except for the fact that it's an API that we know is
m_stone> marcopg_: except for the fact that it's an API that we know is
terrible.
terrible.
Line 489: Line 411:




tomeu> I'm perhaps the person who has suffered more because of the DS
tomeu> I'm perhaps the person who has suffered more because of the DS. I
tomeu> but I have been promised lots of DS replacements
have been promised lots of DS replacements - let me count them... 4!
Four times, I have been promised a DS, and have received only half!
tomeu> let me count them
tomeu> 4
tomeu> 4 times I have been promised a DS, and have received only half




Line 505: Line 425:
new one.
new one.
cjb> marcopg_: I think so too.
cjb> marcopg_: I think so too.
marcopg_> ok, I tend to agree
marcopg_> ok, I tend to agree. (I'm sure there will be people that don't
marcopg_> (I'm sure there will be people that don't though)
though). but that's fine
marcopg_> but that's fine






m_stone> marcopg_: I'm not sure that we should commit to doing much else.
m_stone> marcopg_: I'm not sure that we should commit to doing much else. but
m_stone> marcopg_: but I think we could be confident of achieving that thing.
I think we could be confident of achieving that thing.






tomeu> I think there are cheap alternatives to breaking existing activities
tomeu> I think there are cheap alternatives to breaking existing activities,
tomeu> worth discussing, at least
worth discussing, at least
m_stone> tomeu: I don't think there are cheap alternatives to breaking
m_stone> tomeu: I don't think there are cheap alternatives to breaking
activities that will noticeably improve stability.
activities that will noticeably improve stability. I don't really
m_stone> I don't really believe it.
believe it. But I'm happy to hear your thoughts.
m_stone> But I'm happy to hear your thoughts.
marcopg_> yeah that's a good point
marcopg_> yeah that's a good point


Line 529: Line 447:
different dbus interfaces, etc
different dbus interfaces, etc
m_stone> tomeu: what does that have to do with the causes of failure in the
m_stone> tomeu: what does that have to do with the causes of failure in the
present system?
present system? (which I believe are primarily bitrot and invalid
m_stone> tomeu: (which I believe are primarily bitrot and invalid assumptions)
assumptions)
tomeu> m_stone: was referring to maintain API compatibility, while revamping
tomeu> m_stone: was referring to maintain API compatibility, while revamping
all of it
all of it
Line 540: Line 458:
on the ds
on the ds
m_stone> marcopg_: I'm very confident in him (modulo the risk that he gets
m_stone> marcopg_: I'm very confident in him (modulo the risk that he gets
sick, gets run over by a bus, gets "promoted", etc.) :)
sick, gets run over by a bus, gets "promoted", etc.) :) - recall
olpc-update... once he understand a problem, he's quite difficult to
m_stone> marcopg_: recall olpc-update
stop.
m_stone> marcopg_: once he understand a problem, he's quite difficult to stop.
marcopg_> then let's do it ;) and let's figure out how to properly resource
marcopg_> then let's do it ;) and let's figure out how to properly resource
network without Scott, it doesn't seem impossible
network without Scott, it doesn't seem impossible
Line 553: Line 471:
unchanged, so most activities won't require any modification
unchanged, so most activities won't require any modification
tomeu> bemasc: we have some problems with that API, I'm not sure yet how to
tomeu> bemasc: we have some problems with that API, I'm not sure yet how to
solve them
solve them... well, we overcome those by redesigning, and use those
tomeu> m_stone: well, we overcome those by redesigning, and use those
techniques for old activities not breaking afterwards
techniques for old activities not breaking afterwards


Line 560: Line 477:


m_stone> marcopg_: let's see if we can get some better information from the
m_stone> marcopg_: let's see if we can get some better information from the
deployment & sales folks first.
deployment & sales folks first. even if it takes us a week to make a
m_stone> marcopg_: even if it takes us a week to make a decision, it will be
decision, it will be time well spent if it winds up being a better
time well spent if it winds up being a better decision.
decision. many times over.
m_stone> marcopg_: many times over.
marcopg_> m_stone: I agree
marcopg_> m_stone: I agree


Line 571: Line 487:


bemasc> m_stone: it would be very nice to have a list of desired legacy-Linux
bemasc> m_stone: it would be very nice to have a list of desired legacy-Linux
programs
programs. the only ones I know of are gnumeric and inkscape
bemasc> m_stone: the only ones I know of are gnumeric and inkscape
m_stone> bemasc: agreed. (though tomeu & marcopg rightly suggest that flash &
m_stone> bemasc: agreed. (though tomeu & marcopg rightly suggest that flash &
java might also be good compatibility targets)
java might also be good compatibility targets)
Line 578: Line 493:
essentially out of our hands
essentially out of our hands
m_stone> bemasc: totally false. we can decide to ask developers to work on
m_stone> bemasc: totally false. we can decide to ask developers to work on
gnash or not.
gnash or not. rsavoye has repeatedly said that gnash is shorthanded.
we've just never tried to actively assist him.
m_stone> bemasc: rsavoye has repeatedly said that gnash is shorthanded.
m_stone> bemasc: we've just never tried to actively assist him.




Line 588: Line 502:
marcopg_> tomeu: it would require to refactor the code heavily
marcopg_> tomeu: it would require to refactor the code heavily
tomeu> marcopg_: yeah, but how many months would take it to you?
tomeu> marcopg_: yeah, but how many months would take it to you?
marcopg_> tomeu: that doesn't scale
marcopg_> tomeu: that doesn't scale - we can't embed every possible application
marcopg_> tomeu: we can't embed every possible application
m_stone> tomeu: this would not improve compatibility though.
m_stone> tomeu: this would not improve compatibility though.


Line 597: Line 510:
been solved yet
been solved yet
m_stone> tomeu: scott apparently looked at inkscape when he was writing his
m_stone> tomeu: scott apparently looked at inkscape when he was writing his
icon editor
icon editor - he thinks it would be quite hard to sugarize. (I don't
fully understand why)
m_stone> tomeu: he thinks it would be quite hard to sugarize
m_stone> (I don't fully understand why)






bemasc> but for both gnumeric and inkscape, the datastore is still not the
bemasc> but for both gnumeric and inkscape, the datastore is still not the
problem
problem because both of them use the standard OS-provided open/save
dialogs, which sugar can substitute for DS-based dialogs
bemasc> because both of them use the standard OS-provided open/save dialogs,
which sugar can substitute for DS-based dialogs
tomeu> marcopg_: I have heard gnumeric and inkscape, only
tomeu> marcopg_: I have heard gnumeric and inkscape, only
bemasc> marcopg_: there really aren't very many applications
bemasc> marcopg_: there really aren't very many applications
Line 615: Line 526:
tomeu> marcopg_: we are getting back to the same point: we need to have
tomeu> marcopg_: we are getting back to the same point: we need to have
someone from the ministries of education to tell us which legacy
someone from the ministries of education to tell us which legacy
applications they feel the need for
applications they feel the need for. we are struggling to provide
tomeu> we are struggling to provide features that maybe nobody will
features that maybe nobody will appreciate, while failing to provide
appreciate, while failing to provide the important ones
the important ones






marcopg_> if I want to write a cool application for sugar
marcopg_> if I want to write a cool application for sugar, I know that it will
marcopg_> I know that it will be always confined to that platform
be always confined to that platform and honestly I can see how it's
marcopg_> and honestly I can see how it's not an appealing perspective
not an appealing perspective. we have the possibility to change this
marcopg_> we have the possibility to change this situation without a lot of
situation without a lot of effort and so I think we should do it.
effort
marcopg_> and so I think we should do it
bemasc> marcopg_: yes. It's just a question of priority.
bemasc> marcopg_: yes. It's just a question of priority.
homunq> marcopg_++ on should, no opinion on can
homunq> marcopg_++ on should, no opinion on can
Line 633: Line 542:


tomeu> marcopg_: you, as a good software developer, will abstract the
tomeu> marcopg_: you, as a good software developer, will abstract the
platform dependent code
platform dependent code.
tomeu> ok, we more or less agree on the outcome, I think
marcopg_> tomeu: don't design your platform for very good software developers
marcopg_> tomeu: don't design your platform for very good software developers
tomeu> marcopg_: my point is not if we should do something or not, what I
tomeu> marcopg_: my point is not if we should do something or not, what I
mean is that I'm not convinced of the urgency of this code-on-xo run-
mean is that I'm not convinced of the urgency of this code-on-xo run-
everywhere requirement
everywhere requirement. the current DS API is insufficient no matter
tomeu> the current DS API is insufficient no matter what we decide. and we
what we decide. and we have already devised a scheme for legacy
have already devised a scheme for legacy applications to store its
applications to store its files in the journal. where are we
files in the journal
differing?
tomeu> where are we differing?




Line 649: Line 556:


marcopg_> I think it would make for a much better experience for developers
marcopg_> I think it would make for a much better experience for developers
which start working on sugar
which start working on sugar. it would put us in a better position in
marcopg_> it would put us in a better position in the case of a end-of-funding
the case of a end-of-funding and it will make more likely that our
marcopg_> and it will make more likely that our applications are reused outside
applications are reused outside sugar. I think those are pretty
strong reasons and I argue the effort is minimal.
sugar
marcopg_> I think those are pretty strong reasons
marcopg_> and I argue the effort is minimal




Line 665: Line 570:
tomeu> marcopg_: we can make files dropped in ~/Documents to appear in the
tomeu> marcopg_: we can make files dropped in ~/Documents to appear in the
journal as well as possible. but those apps won't be able to give a
journal as well as possible. but those apps won't be able to give a
so good experience as an activity
so good experience as an activity. no matter what we do, "You created
the document My Dog with the application Gimp" is not as good as "You
tomeu> no matter what we do
tomeu> "You created the document My Dog with the application Gimp" is not as
drawed My Dog with Tim and Silvia".
good as "You drawed My Dog with Tim and Silvia"
marcopg_> tomeu: apps not specifically designed for sugar will never give you
marcopg_> tomeu: apps not specifically designed for sugar will never give you
an as good experience as an activity, but that's fine
an as good experience as an activity, but that's fine
Line 679: Line 583:


tomeu> and I think we agree in that the current DS API will need to be
tomeu> and I think we agree in that the current DS API will need to be
scraped, right?
scraped, right? well, the problem is that nobody is discussing what I
tomeu> well, the problem is that nobody is discussing what I think needs to
think needs to be discussed
be discussed
marcopg_> tomeu: what do you think needs to be discussed... :)
marcopg_> tomeu: what do you think needs to be discussed... :)
tomeu> marcopg_: what will be the new API(s)
tomeu> marcopg_: what will be the new API(s)
marcopg_> my suggestion about that would be to look into scott prototype
marcopg_> my suggestion about that would be to look into scott prototype and
marcopg_> and build a prototype UI on the top of it
build a prototype UI on the top of it. that would give us a much
marcopg_> that would give us a much better base to discuss on
better base to discuss on. Scott is in charge of designing the API -
the more feedback he gets, better the API will be. I'm not really a
marcopg_> Scott is in charge of designing the API
fan of a long abstract discussion of an API, without experimenting
marcopg_> more feedback he gets, better the API will be
with it.
marcopg_> I'm not really a fan of a long abstract discussion of an API, without
experimenting with it
tomeu> marcopg_: well, activity authors may be able to provide something
tomeu> marcopg_: well, activity authors may be able to provide something
more close to their real needs
more close to their real needs - I don't think we are at the point
marcopg_> I don't think we are at the point where activity authors feedback is
where activity authors feedback is useful, yet
useful, yet
marcopg_> when olpcfs is more mature, that will certainly be useful
marcopg_> when olpcfs is more mature, that will certainly be useful


Line 703: Line 604:
Blaketh> tomeu: Can you point me towards some failings of the current DS API?
Blaketh> tomeu: Can you point me towards some failings of the current DS API?
bemasc> activity authors are pretty much happy with the current high-level
bemasc> activity authors are pretty much happy with the current high-level
API, which is what almost all of them use
API, which is what almost all of them use. the only significant issue
bemasc> the only significant issue is an inability to save multiple files as
is an inability to save multiple files as a single entry
a single entry
marcopg_> bemasc: well that's your opinion. I heard a bunch of complaints about
marcopg_> bemasc: well that's your opinion. I heard a bunch of complaints about
the current API, and I've seen a bunch of confused developers
the current API, and I've seen a bunch of confused developers
tomeu> Blaketh: see http://wiki.laptop.org/go/DatastoreOpenIssues
tomeu> Blaketh: see http://wiki.laptop.org/go/DatastoreOpenIssues. being
tomeu> being able to update a file without having to copy it around is one
able to update a file without having to copy it around is one missing
missing point
point.
tomeu> bemasc: we could use cow
tomeu> bemasc: the issue here is API. right now, activity authors need to
bemasc> tomeu: every CoW filesystem copies the whole file on write
copy the whole file to a temp dir, modify it, and submit again to the
DS. it's the same at the end, but would be good if activity authors
tomeu> bemasc: the issue here is API
weren't concerned about how the DS stores data. the DS passes a path
tomeu> right now, activity authors need to copy the whole file to a temp
dir, modify it, and submit again to the DS
where the activity can read or write to so the DS should make the
tomeu> it's the same at the end, but would be good if activity authors
copy. after the activity is happy with it, commits to the DS, no
weren't concerned about how the DS stores data
matter if the activity is Read, VideoEditor, etc
tomeu> the DS passes a path where the activity can read or write to
bemasc> so the DS should make the copy
tomeu> after the activity is happy with it, commits to the DS
tomeu> no matter if the activity is Read, VideoEditor, etc






bemasc> anyone thinking about legacy compatibility should know about
bemasc> anyone thinking about legacy compatibility should know about
http://www.pygtk.org/docs/pygtk/class-gtkfilechooser.html
http://www.pygtk.org/docs/pygtk/class-gtkfilechooser.html - Sugar can
bemasc> Sugar can provide its own filechooser, thus integrating any GTK
provide its own filechooser, thus integrating any GTK application
application with the datastore without fancy filesystem footwork, and
with the datastore without fancy filesystem footwork, and without
without ever showing paths to the user
ever showing paths to the user
tomeu> bemasc: well, using the fs as a means for getting things into the
tomeu> bemasc: well, using the fs as a means for getting things into the
journal is better than that, right?
journal is better than that, right?

Revision as of 01:09, 11 April 2008

Initial Unhappiness

 m_stone> I take it that you guys are concerned that you'll have sugar in a
          releasable state say around mid-June or early July? and that you'll
          be unable to make big changes for the remainder of the 1-1.5 months
          until the release?
   tomeu> well, I think the issue is not releasing something like last
          releases; some thing that more or less works but having a better API
          and based on components that are more predictable
   tomeu> "something that more or less works" == "something that passes the
          minimal QA work that has been done but that shows critical problems
          after being deployed" - we are not happy how new features have been
          rolled out


 m_stone> tomeu: keep explaining, please. I really want to understand what
          things look like from your vantage point. (incidentally, that sounds
          more like a QA failure rather than a software team failure to me.)


   tomeu> m_stone: building on an orphaned component like the DS is not very
          nice, either. well, project issues that needs to be solved - we
          cannot blame QA because it has been composed by interns
     cjb> and is currently composed of no-one :)
   tomeu> we already complained last summer about interns leaving just when
          they started being useful. Also, I'm not happy with the parts of the
          sugar API that I have contributed most, either




Present Unhappiness

 m_stone> tomeu: help me understand how this affects the work you think we
          should undertake to do for August 1 or the next release beyond.
   tomeu> m_stone: we want to have a software architecture more resilient to
          bugs, more maintainable, and want to give activity authors a better
          API. nothing of that are new features from the POV of the project
          manager, I think. just dedicate time to it ;). Then discuss, discuss,
          discuss, then implement, deploy.


   tomeu> so well, we have a problem deciding on what to spend time - every few
          months we are promised a new DS. the activity API depends on that so
          it's not evolving and really sucks because depends on important
          implementation things like storing entries with delta compression. so
          well, we would like to better plan things, and spend effort in
          invisible features


 m_stone> tomeu: cscott, cjb, and I spent several minutes yesterday debating
          whether cscott should try to fix networking things or DS things. (and
          consequently whether cjb should fix networking things or power
          things). (and whether the kernel folks should fix power things or
          ???). (and whether I should concentrate on collaboration or
          stability/compatibility things). we have two plans and we haven't
          figured out yet which one is better.


   tomeu> m_stone: right, that's also our problem. I was supposed to work in
          the journal. but had to choose between sugar, read, browse, ds, etc.
          at different points and performance


How should we allocate effort?

 m_stone> marcopg_: plan a) is cscott, cjb, & kernel folks on networking,
          mstone & collabora on collaboration, and sugar on ??? where ??? is
          probably the as yet unspecified "UI features that are already in the
          bag + any accessible stability". the other plan is cscott on DS, cjb
          on limited cases of power, kernel folks on power, mstone on ???, and
          sugar on ??? where ??? is the same as above.
     cjb> I think there's a third plan of cscott, mstone and collabora on
          networking, cjb and kernel on power, sugar on ???.
marcopg_> I'm not sure I understand why we are going through the two extremes
          about networking
marcopg_> we certainly need someone on it, but I doubt putting the whole team
          on it will help


 m_stone> I'll try to answer marcopg's question and I'll try to explain the
          other flaws here. first flaw: someone has to manage the release. at
          present, I'm the default candidate (though feel free to suggest
          others). that's not immediately a full time job. but it will turn
          into one and we can't forget it. also, effort will need to shift in
          the second half of the cycle toward making it happen.  i.e. the
          release manager will need to impose on erikos, or cjb, or... :)


 m_stone> second problem: there is lots of debate about how many people can
          profitably work on networking, on power, on collaboration, on UI, on
          "stability", or on "compatibility". in part, debate exists because
          there are different approaches to each of these problems.


Power Management

 m_stone> i.e. one way to do power is to make it work in limited circumstances.
          I think of this as the "low-hanging fruit" approach. It mainly
          requires cjb + some kernel, we think.
marcopg_> some kernel == not full time kernel person?
     cjb> Yeah.  I'd be surprised if we can't come up with an acceptable
          limited/incremental use of power that takes less than a day to
          implement.  I'll try to write something about this. For example, we
          don't do power management if you're currently connected to a jabber
          server, else we do.


 m_stone> the other way to deal with power (over a longer time frame) is to
          comprehend the networking stack (so that we know what timeouts &
          wakeups are needed), to fix the kernel to make those timeouts &
          wakeups occur, then to do more userland power management. similarly
          for networking.
     cjb> (There are still the timeouts.  It's hard to know how to tackle them,
          when no particular misbehavior has ever been reported due to them.)


Networking

 m_stone> one way to approach networking is to write down a believable
          networking architecture, then to follow through. (where a believable
          networking architecture would contain a small number of protocols
          that "stretch" to cover all of our present use cases). the other way
          is to try to follow the critical path toward one use case (e.g.
          reliable read sharing on a school server wifi with K/N laptops) and
          to fix every damn bug you find along the way until it works or until
          you recognize defeat. the latter might get you a single working use
          case (or maybe 3), but it's not going to get you reliability,
          stability, or leverage. (they also take different amounts of time)


Focus or Divide and Conquer?

   morgs> Are the approaches mutually exclusive from a resource point of view?
     cjb> morgs: my third approach does a fairly even split of three groups
          into three things. we can argue that this *sort* of approach has been
          the main problem with OLPC software development and has led to power
          management that doesn't really work, a mesh that doesn't really work,
          collaboration that doesn't really work, and a datastore that doesn't
          really work.
 m_stone> and, as cjb alluded, we presently feel like we have N demos rather
          than 1 solid product. some people believe this is because we sent N
          people in N+2 directions rather than either sending 10N people in N+2
          directions or sending N people in, say, 3 directions


marcopg_> I don't think that's matter of people; it's matter of too many
          ambitious goals


   tomeu> I don't think that having twice the number of people would have been
          a waste of resources - in many projects it is, but in our case...
 m_stone> marcopg_: the complete absence of a QA team definitely made itself
          felt here... (and the absence of software attacking the QA problem,
          e.g. test suites)
   tomeu> the absence of a DS maintainer, too


   tomeu> the problem is that it depends on what we aim to do and, regarding
          sugar, we just don't know right now... perhaps later today


marcopg_> let me rephrase: I don't think moving everyone to work on the network
          will help the network a lot, at least on 4 months schedule. gradually
          adding people to the current team would be much more sensible, ihmo


 m_stone> marcopg_: a) I think scott proposes to make sure that every aspect of
          networking has at least one person working on it; not to make
          everyone work on it regardless of whether they are doing something
          useful
 m_stone> marcopg_: b) why, precisely, do you anticipate that (a) would fail?
          (or would be too expensive to pursue?)


marcopg_> because it takes time for people to figure out how to work together
          in a productive way. if we have uncovered areas then we should cover
          them. which aspects of networking we are not covering right now?


   tomeu> m_stone: do you think that many of our orphaned or under-resourced
          areas can only be tackled efficiently for people already in the team?
          (in this case, without wasting most of the new resources' potential)
 m_stone> depends what you mean by "efficiently"; specifically: I think that we
          have individuals who have the experience required to 'begin labor' on
          many areas but I don't feel that they'll have the ability to close
          noticeable numbers of bugs


   tomeu> if we talk about how to distribute resources, we need to characterize
          every area as in how high is the entry point. some areas will require
          a longer effort to start being productive, some less


OLE Nepal: Journal & Datastore

 BryanWB> hey guys, if you dont' mind i have a few ideas of where OLPC should
          put its resources. I think OLPC should focus on the datastore and
          Sugar over the next serveral months, whether that means putting all
          or most of your human resources towards that. W/ the
          datastore/Journal being most important. the networking and power work
          well enough but it is fairly difficult to use the Journal to find
          stuff. Also, in my week's worth of QA, Sugar just does unexpected
          stuff. Over the last 2 weeks of working w/ os699, then 702, now 703,
          I have had the most problems w/ the Journal/datastore then Sugar
          weirdness.
marcopg_> I tend to agree with BryanWB, simply because the Journal is more a
          base/fundamental use case then network sharing; i.e. losing your work
          is more critical then not being able to share an activity


     cjb> I think my counter-argument would be that if you live somewhere with
          ample power, have a wireless AP and only one XO, of course you're
          going to say that networking and power work fine.  :)
 BryanWB> cjb: we are using an AP not active antenna
     cjb> BryanWB: Yes.  That's why I say it's natural that you would think it
          works fine. What *doesn't* work is the mesh (non-AP) layer.
 m_stone> cjb: rather, our choice of protocols and implementations is
          incompatible with the mesh. (I speak relationally because I suspect
          that we are more likely to change the protocols & implementations
          than we are to change the firmware)


 BryanWB> cjb: I know, but that doesn't work anyway when you've got 70 XO's at
          one school, AFAIK. mesh is less important than basic usability of
          datastore
   tomeu> BryanWB: that's another problem we have, knowing the very different
          problems of every deployment location. I think peru's next
          deployments will use mainly mesh, but I'm not sure.
 BryanWB> tomeu: they can buy a small AP and power backup for Peruvian schools.
          Power backup is pretty ubiquitous anywhere they have electricity and
          load-shedding. ** at least in south and east asia **  don't know
          south america
     cjb> BryanWB: what about when the kids go home from school, though?


  erikos> i think both are important use cases mesh and datastore and should
          both be addressed - i hope that for august we can do both - at least
          parts. we once started to provide mesh usability - and should
          continue to push for it; i think the statement that the datastore
          should work is out of question
     cjb> the problem is that no-one is confident we can get there by pushing,
          rather than by throwing out what we have and redesigning. I guess
          then we come to a question of whether the datastore can also be made
          to work properly incrementally.


 BryanWB> cjb: it needs to work at school first, that's where the other kids
          are and they spend 8+ hours per day. Home should be a lower priority
     cjb> since cscott's time is one of the main variables here, and he'd be
          doing olpcfs.
 m_stone> cjb: well, we might be able to have two people work on it. for
          example, one person could start implementing the testing!
  erikos> cjb: sure - i mean if we feel we have to throw something out - we
          might have to keep a beta solution in the hands as well. in the case
          of the datastore - if we decide we rewrite (i think that is what
          people feel) we should start now
     cjb> I think the short answer is that we shouldn't have to be making these
          decisions ourselves.  But if we write them up clearly enough, we can
          pass the decision up the chain.
   tomeu> having to choose between mesh and datastore is like choosing between
          drinking or eating - both are needed


Feedback from Peru?

 m_stone> so two questions: 1) what have the peruvian teachers discovered about
          703? carla was clearly upset about a mesh bug.
marcopg_> m_stone: that's something that the deployment team should figure out
          - we just don't have enough information at the moment to say it
 m_stone> marcopg_: in which case the priority should be to get that
          information, yes? or to change the decision so that it's no longer
          necessary.
marcopg_> m_stone: I think that should be the priority, yeah


What is "compatibility"?

 m_stone> marcopg_: you say the "compatibility" requirement is "unknown"?
marcopg_> m_stone: I don't know why it has been suddenly added to the list of
          top reqs. (I'm not against, I'd just like to understand better)


 m_stone> marcopg_: first, let's make sure we mean the same thing.
          compatibility means two things: 1) our software running on other
          people's platforms and 2) other people's software running on our
          platform.


 m_stone> we mean both of these, I think.
marcopg_> but there are a lot of possible approaches with pretty different end
          results and that's the main reason I want to know why it was pushed -
          to figure out solutions that meets the exact requirements
  bemasc> cscott specifically referred to #2, not #1


Why do we want it?

 m_stone> agreed that the reasoning behind making it a priority has not been
          explained - I'll try to articulate the justification. 1) we wish more
          people were supporting our platform. We thing that there are two ways
          to do this - first, to bring our software to them, and second, to
          give them an immediate userbase running on our platform and 2) we're
          concerned, from time to time, that the days of funded support for our
          platform are limited; therefore, we wish it to be less expensive to
          maintain.


marcopg_> how much limited? 1-2 years or 1-2 months? ;)
 m_stone> marcopg_: we've been greatly reassured on this point in recent weeks.
          (specifically by the fact that kim's budget was accepted). but I
          think that anxiety is a driving factor in the desire to increase
          compatibility. as for your question: "both, with different
          liklihoods"


   tomeu> we are having to guess too much, considering we have kids using the
          laptops in the thousands and adding anxiety to the guessing...
 m_stone> tomeu: I say the same thing all the time but I don't know what to do
          about it. the anxiety has greatly abated. we are now confident enough
          in survival to begin hiring.


Who wants it and how?

marcopg_> m_stone: do we expect countries to actually deploy machines with
          standard applications installed? and are we going to encourage or
          discourage it?
marcopg_> the degree of compatibility we need is also an important factor for
          the datastore work even though I think we will be forced to do
          *something* about the datastore situation by august
   tomeu> m_stone: which legacy software needs to be run in the laptops and
          which problems it has? if it's flash apps, then the compatibility
          stuff gains a totally different meaning if it's java, we may have
          different problems than APIs


 m_stone> marcopg_, tomeu: excellent questions which I do not have
          authoritative answers for.
marcopg_> m_stone: ok, that's a question we need to answer I think


How does it affect the DS (and other APIs)?

   tomeu> m_stone: I wonder why the compatibility thing is so tied to a new DS
 m_stone> tomeu: because of the desire to use the journal as the only
          navigation tool pointing to local persistent data
   tomeu> from my pov, the same mechanisms that olpcfs has for that, could be
          added on top of the current implementation. we could add a fuse
          thingy on top of the current DS
 m_stone> tomeu: I'm skeptical that the current DS would withstand that much
          stress...
marcopg_> yeah what m_stone said
   tomeu> m_stone: ok, I'm only concerned of mixing so many different issues
 m_stone> tomeu: it's a good concern. I have no good answers for you :(


   tomeu> we talk about compatibility, but do something because of performance
marcopg_> there is value in the idea of reusing the API though and to start by
          fixing the implementation
 m_stone> marcopg_: except for the fact that it's an API that we know is
          terrible.
     cjb> I don't think we should be too afraid about breaking APIs, if we have
          a principled reason for doing it.  It happens.


  bemasc> I don't think there is very much legacy software worth using
marcopg_> m_stone: it is, but we have tons of activities using it out there
 m_stone> marcopg_: not very many, actually.
marcopg_> so in some way we will probably need to keep supporting it


   tomeu> I'm perhaps the person who has suffered more because of the DS. I
          have been promised lots of DS replacements - let me count them... 4!
          Four times, I have been promised a DS, and have received only half!


Can we drop the current DS?

marcopg_> m_stone: do you think we can drop it and ask authors to port? (real
          question)
 m_stone> marcopg_: yes.
     cjb> And we can offer to update all activity code in our git repo to the
          new one.
     cjb> marcopg_: I think so too.
marcopg_> ok, I tend to agree. (I'm sure there will be people that don't
          though). but that's fine


 m_stone> marcopg_: I'm not sure that we should commit to doing much else. but
          I think we could be confident of achieving that thing.


   tomeu> I think there are cheap alternatives to breaking existing activities,
          worth discussing, at least
 m_stone> tomeu: I don't think there are cheap alternatives to breaking
          activities that will noticeably improve stability. I don't really
          believe it. But I'm happy to hear your thoughts.
marcopg_> yeah that's a good point


   tomeu> m_stone: using python namespaces, having daemons exporting two
          different dbus interfaces, etc
 m_stone> tomeu: what does that have to do with the causes of failure in the
          present system? (which I believe are primarily bitrot and invalid
          assumptions)
   tomeu> m_stone: was referring to maintain API compatibility, while revamping
          all of it


marcopg_> personally I think that if we are confident cscott can come up with
          something solid by august, then it's totally worth to have him focus
          on the ds
 m_stone> marcopg_: I'm very confident in him (modulo the risk that he gets
          sick, gets run over by a bus, gets "promoted", etc.) :) - recall
          olpc-update... once he understand a problem, he's quite difficult to
          stop.
marcopg_> then let's do it ;) and let's figure out how to properly resource
          network without Scott, it doesn't seem impossible
  erikos> m_stone: i think as well that it is worth to have at least one person
          focusing on the ds reimplementation


  bemasc> the high-level API will (read(), save(), etc.) will presumably remain
          unchanged, so most activities won't require any modification
   tomeu> bemasc: we have some problems with that API, I'm not sure yet how to
          solve them... well, we overcome those by redesigning, and use those
          techniques for old activities not breaking afterwards


 m_stone> marcopg_: let's see if we can get some better information from the
          deployment & sales folks first. even if it takes us a week to make a
          decision, it will be time well spent if it winds up being a better
          decision. many times over.
marcopg_> m_stone: I agree


In more detail, what do we want?

  bemasc> m_stone: it would be very nice to have a list of desired legacy-Linux
          programs. the only ones I know of are gnumeric and inkscape
 m_stone> bemasc: agreed. (though tomeu & marcopg rightly suggest that flash &
          java might also be good compatibility targets)
  bemasc> m_stone: well, flash doesn't write to disk, so it's immaterial.  It's
          essentially out of our hands
 m_stone> bemasc: totally false. we can decide to ask developers to work on
          gnash or not. rsavoye has repeatedly said that gnash is shorthanded.
          we've just never tried to actively assist him.


   tomeu> about gnumeric, embedding it like we do with abiword shouldn't be
          very complicated
marcopg_> tomeu: it would require to refactor the code heavily
   tomeu> marcopg_: yeah, but how many months would take it to you?
marcopg_> tomeu: that doesn't scale - we can't embed every possible application
 m_stone> tomeu: this would not improve compatibility though.


   tomeu> inkscape, had some memory usage problems that I don't know if have
          been solved yet
 m_stone> tomeu: scott apparently looked at inkscape when he was writing his
          icon editor - he thinks it would be quite hard to sugarize. (I don't
          fully understand why)


  bemasc> but for both gnumeric and inkscape, the datastore is still not the
          problem because both of them use the standard OS-provided open/save
          dialogs, which sugar can substitute for DS-based dialogs
   tomeu> marcopg_: I have heard gnumeric and inkscape, only
  bemasc> marcopg_: there really aren't very many applications
marcopg_> it's not much a problem of existing applications


   tomeu> marcopg_: we are getting back to the same point: we need to have
          someone from the ministries of education to tell us which legacy
          applications they feel the need for. we are struggling to provide
          features that maybe nobody will appreciate, while failing to provide
          the important ones


marcopg_> if I want to write a cool application for sugar, I know that it will
          be always confined to that platform and honestly I can see how it's
          not an appealing perspective. we have the possibility to change this
          situation without a lot of effort and so I think we should do it.
  bemasc> marcopg_: yes.  It's just a question of priority.
  homunq> marcopg_++ on should, no opinion on can


   tomeu> marcopg_: you, as a good software developer, will abstract the
          platform dependent code.
marcopg_> tomeu: don't design your platform for very good software developers
   tomeu> marcopg_: my point is not if we should do something or not, what I
          mean is that I'm not convinced of the urgency of this code-on-xo run-
          everywhere requirement. the current DS API is insufficient no matter
          what we decide. and we have already devised a scheme for legacy
          applications to store its files in the journal. where are we
          differing?


What compatibility might we try to provide?

marcopg_> I think it would make for a much better experience for developers
          which start working on sugar. it would put us in a better position in
          the case of a end-of-funding and it will make more likely that our
          applications are reused outside sugar. I think those are pretty
          strong reasons and I argue the effort is minimal.


  bemasc> tomeu: (I think we need to distinguish between legacy FD.o compliant
          applications and legacy non-FD.o-compliant)


   tomeu> marcopg_: we can make files dropped in ~/Documents to appear in the
          journal as well as possible. but those apps won't be able to give a
          so good experience as an activity. no matter what we do, "You created
          the document My Dog with the application Gimp" is not as good as "You
          drawed My Dog with Tim and Silvia".
marcopg_> tomeu: apps not specifically designed for sugar will never give you
          an as good experience as an activity, but that's fine
   tomeu> as I said, we agree on what needs to be done
marcopg_> then let's just do it :P


How should we try to get there?

   tomeu> and I think we agree in that the current DS API will need to be
          scraped, right? well, the problem is that nobody is discussing what I
          think needs to be discussed
marcopg_> tomeu: what do you think needs to be discussed... :)
   tomeu> marcopg_: what will be the new API(s)
marcopg_> my suggestion about that would be to look into scott prototype and
          build a prototype UI on the top of it. that would give us a much
          better base to discuss on. Scott is in charge of designing the API -
          the more feedback he gets, better the API will be. I'm not really a
          fan of a long abstract discussion of an API, without experimenting
          with it.
   tomeu> marcopg_: well, activity authors may be able to provide something
          more close to their real needs - I don't think we are at the point
          where activity authors feedback is useful, yet
marcopg_> when olpcfs is more mature, that will certainly be useful


Why is the current DS API unhappy?

 Blaketh> tomeu: Can you point me towards some failings of the current DS API?
  bemasc> activity authors are pretty much happy with the current high-level
          API, which is what almost all of them use. the only significant issue
          is an inability to save multiple files as a single entry
marcopg_> bemasc: well that's your opinion. I heard a bunch of complaints about
          the current API, and I've seen a bunch of confused developers
   tomeu> Blaketh: see http://wiki.laptop.org/go/DatastoreOpenIssues. being
          able to update a file without having to copy it around is one missing
          point.
   tomeu> bemasc: the issue here is API. right now, activity authors need to
          copy the whole file to a temp dir, modify it, and submit again to the
          DS. it's the same at the end, but would be good if activity authors
          weren't concerned about how the DS stores data.  the DS passes a path
          where the activity can read or write to so the DS should make the
          copy. after the activity is happy with it, commits to the DS, no
          matter if the activity is Read, VideoEditor, etc


  bemasc> anyone thinking about legacy compatibility should know about
          http://www.pygtk.org/docs/pygtk/class-gtkfilechooser.html - Sugar can
          provide its own filechooser, thus integrating any GTK application
          with the datastore without fancy filesystem footwork, and without
          ever showing paths to the user
   tomeu> bemasc: well, using the fs as a means for getting things into the
          journal is better than that, right?