Please update etoys in 8.2.1

[Daniel Drake]

2009/2/6  <david at lang.hm>:
> sorry if I seem like a pest, and I definantly do appriciate the volunteers
> here, but what I am trying to understand here are the plans of the olpc
> orginiztion itself. it's one thing to transition the maintinance of the
> Sugar UI to an outside orginization, it's something very different to
> switch from Sugar the distro (or whatever you want to call it if not
> Sugar) to Fedora with the Sugar UI running in it.
>
> among other things, this would signal the end of the rainbow security
> approach in favor of standard linux (or possibly SElinux) security.
>
> It would end the dual image 'hit a button to boot the last image' approach
> as standard distros don't do that. and probably several other things.
>
> I'm not even saying it's the wrong thing to do. I'm just trying to
> understand what the plan is.

I can only speak as a volunteer too, but I can speak as one who
intends to continue contributing to development, and I have
participated in the discussions:

The "plan" makes more sense when you look at it from a high level.
OLPC used to have a fairly significant development team, and a QA
group. It did a lot of development and testing. Now, there are only a
couple of developers and no QA team. It's not practical to continue
developing as happened before.

Now, imagine if we could use someone elses software, e.g. Fedora, with
no modifications (ignoring any loss of features, or let's say that no
features are lost). Fedora have a release cycle, a QA team, a big
community-based development group, etc. OLPC can continue shipping the
same kind of thing on the machines, progressing at a similar or faster
rate than previously, and it can do this with only a few staffers.
This would be a perfect solution to the current problem.

It sounds great, but there are challenges: OLPC has historically
diverted from upstream and developed technologies in-house which have
not really been pushed at or adopted by other communities. e.g.
olpc-update, rollback boot, ...
OLPC has also made some hacks to packages to better meet the goals of
the organisation, at the expense of maintainability of the OS. This
cannot continue in such a model where no modifications are made.

So, the community (and couple of devs at OLPC) now needs to work on
taking each of those hacks and features and integrating them into
upstream-upstream (by that I mean the actual real upstream codebases,
not just Fedora upstream) in a non-hacky way. Then the rest of the
world has the technology too, and more significantly, the rest of the
world maintains the technology (not OLPC).

Yes, this is hard, and F11 may regress some features such as the ones
you mention. But, by the very nature of the system, anything that is
*properly* integrated for F11 will *automatically* be present in F12,
F13, etc. So, given the large amount of community interest, I am
confident we'll get there given time. Maybe not F11, but after.

Let's also not forget that OLPC's target is deployments.. Some of the
features have not seen much adoption. For example, rollback boot... At
least in the deployment scenarios I have been involved in, NAND space
is a commodity and we cannot afford having 2 OSs there (they want many
activities, wikipediaEN/ES, gcompris, a few hundred mb of textbooks,
etc). Although it would be a shame to lose such a feature, it is not
something that I would see blocking adoption by the majority of
deployments.

Daniel