I've been thinking about this problem for the last year -- when it first became obvious (to me) that:<br><br>1 - we were definitely NOT going to be able to lock down APIs for at least a year or two<br>2 - we have no control over the activity developers and the maintainability of any given activity (unless we decide to 'own' it)<br>
3 - all standard 'best practices' for ensure that 'customers' can keep working seamlessly through upgrades have to be dropped for the OLPC project<br><br>And the only 'real' solutions I have come up with are: <br>
<br>1 - completely separate the activities from the OS in order to help people understand that most activities are NOT supported or maintained by OLPC; they need to be able to upgrade activities as needed and not wait for new releases from OLPC<br>
2 - push for 'school year' releases (fall and spring); where a school will pick a release and use it for the entire school year so we don't have to worry about upgrades in between that time<br><br>and, most recently you will hear me pushing for:<br>
<br>3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year.<br>
<br>If schools agree that this a good idea (it also wipes all the data and provides students with a lot more room); then what I would push for is that saved data can continue to work on upgraded activities -- this is something that the activity developers have to worry about, but it decreases the test effort quite a bit and recommends that schools retest activities between school years. <br>
<br>Kim<br><br><br><br><br><div class="gmail_quote">On Mon, Jul 14, 2008 at 9:14 AM, Greg Smith <<a href="mailto:gregsmitholpc@gmail.com">gregsmitholpc@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi All,<br>
<br>
Responding to all in one pass.<br>
<br>
 From Scott -<br>
<div class="Ih2E3d">> The general solution to this problem is trac #4951, the activity<br>
> updater, which I've landed recently.  Trac #7495 says that the first<br>
> boot after an upgrade should open the activity updater, so that a<br>
> version of the activity compatible with the new OS can be installed if<br>
> necessary.  The activity update protocol understands simple base OS<br>
> dependencies, so that you can specify a different version for 8.1 and<br>
> 8.2 (for example).  The [[Activity_bundles]] wiki page documents the<br>
> update_url tag.<br>
<br>
</div>GS - Sounds good but it still requires all activity developers to update<br>
their activities which I think is the central problem. Also, we still<br>
need to warn users in advance, especially if they upgrade via USB.<br>
Definitely will help so let's do it if its not too much work.<br>
<br>
 From Michael -<br>
2 -<br>
<div class="Ih2E3d">> Off the top of my head:<br>
><br>
>   Activity toolbars<br>
>   Bitfrost protections<br>
>   Power-management work<br>
>   Datastore APIs<br>
>   Collaboration APIs<br>
>   APIs which hamstring our software on other distributions<br>
<br>
</div>GS - How certain are these and is there any documentation of them or<br>
what activity changes they will require? We should agree that they are<br>
must have items worth requiring activity upgrade before doing them and we<br>
should document what it will cost activity developers if we do.<br>
<div class="Ih2E3d"><br>
> As above - it is our responsibility, when making breaking changes, to<br>
> help carry our downstream partners along with us.<br>
</div>and related comments<br>
<br>
GS - Does anyone have the contact info for the developers of all the<br>
currently available activities? Can we document the changes they need to<br>
make in 8.2.0 and contact them? Let's also ask them what they think<br>
about us requiring they rewrite in each release.<br>
<div class="Ih2E3d"><br>
>> If we can define "well behaved" and not test activities that meet that<br>
>> criteria it will save us a lot of test time.<br>
><br>
> As hinted above, I do not believe that we can spare activities from API<br>
> breakage. At best we can somewhat increase the amount of time in which<br>
> it is possible run software based on deprecated assumptions.<br>
<br>
</div>GS - I'm asking if we can tell developers "here are the things you can<br>
do which will be safe". That is, make some kind of promise of backward<br>
compatibility for some subset of all functionality.<br>
<div class="Ih2E3d"><br>
>  <a href="http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html" target="_blank">http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html</a><br>
>   <a href="http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html" target="_blank">http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html</a><br>
>   <a href="http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html" target="_blank">http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html</a><br>
<br>
</div>GS - Will read Monday, thanks.<br>
<div class="Ih2E3d"><br>
>> e.g. can we say that all activities not listed on this page:<br>
>> <a href="http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4" target="_blank">http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4</a> will<br>
>> work the same in 8.2.0 as they did in previous releases?<br>
><br>
> Your statement is too ambiguous to safely promise. Can you be more<br>
> precise about what you actually want to promise?<br>
<br>
</div>GS - I thought it was precise :-) and I meant "not". I want to know if<br>
we can promise that *any* activities will continue to work. I hoped that<br>
these Sugar activities are the only ones using some APIs (e.g.<br>
collaboration) and therefore the only ones susceptible to breakage.<br>
<div class="Ih2E3d"><br>
<br>
>> In the future if some piece of core code will cause previously<br>
supported<br>
>> activities to no longer work, I hope we can discuss and accept or<br>
reject<br>
>> that in advance (sorry if I missed that debate on this round).<br>
><br>
> Again, please say more about what you're thinking of.<br>
<br>
</div>GS - I'm saying let's make sure to discuss and agree before making any<br>
API changes that might break activities.<br>
<br>
> Tuesday call?<br>
><br>
<br>
GS - Sorry I meant Tuesday software IRC/Gabble meeting. We are on for<br>
Tuesday and Wed. again this week at the same times, right?<br>
<br>
RE: Marco's comments.<br>
<br>
GS - Thanks! Can you start adding the names of all activities that we<br>
know should/will work to the Release notes too?<br>
<br>
How does someone know what version they have of an activity in Fructose<br>
or Glucose?<br>
<br>
Its helpful to claim "backward compatible" from Update.1. However, I<br>
believe many people will be upgrading from 656 too. Maybe we have to<br>
say: "upgrade all your activities" in that case?<br>
<br>
**********<br>
A few more questions on this:<br>
- Leaving aside how its done technically, I believe that Linux<br>
distributions are fully backward compatible. That is, you can go to the<br>
latest supported Distribution and leave your Firefox (or any<br>
application) on its older release and it will still work fine. Let me<br>
know if that is not correct. I think that is what we need to strive for,<br>
eventually.<br>
<br>
- Black box testing of all activities is not feasible unless the<br>
authors do it themselves. Can we grep all the activity source code for<br>
the functions (or objects or whatever) that have changed and determine<br>
which activities might break? I haven't learned much about activity<br>
creation and bundling yet so pardon my ignorance if this is a naive<br>
question.<br>
<br>
Until we get a better grip on "downstream" relationships with activity<br>
authors I think the only short term answer is better documentation.<br>
<br>
Can someone put up a wiki page that explains what has changed and tells<br>
activity authors what they need to check in their code to determine if<br>
they are still compatible?<br>
<br>
Bobby,<br>
<br>
Are you ready to upgrade your activity every 6 months? Do you promise?<br>
:-) Do you know what to do in this release?<br>
<br>
**********<br>
Sorry for the long thread but I'm worried. If any significant activities<br>
fail on upgrade, users will hit the roof. Users don't know the<br>
difference between the OS and the activities (not sure I do either :-).<br>
They just know something used to work and after we told them to upgrade<br>
it doesn't.<br>
<br>
Imagine someone walking 20 hours through the jungles of Peru with a<br>
USB stick. Upgrading a remote school then finding out they can't save in<br>
Write or TamTam. They can downgrade (kudos to whoever built that!) but<br>
he has to walk 40 more hours now to fix it. If he read the release notes<br>
and there was no mention of this, that will be one angry technician!<br>
<br>
Hopefully I'm being too conservative and 8.2.0 will go easy so we have<br>
more time to come up with a plan...<br>
<br>
Thanks,<br>
<br>
Greg S<br>
<div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
</div></div></blockquote></div><br>