<div dir="ltr">Actually, Tomeu, What's the state of #7220? It's still open, but I thought this was already taken care of by including a "default" activities.default in the build, so that even if the country doesn't supply one, kids don't get an empty screen.  I agree that G1G1 is a place where this problem is most likely to surface, and it's something we do need to handle smoothly.  But, even then, don't we also ship a "fructose" (including a default set of activities) on G1G1 laptops, too?  We can easily build the image for this to include an activities.default.<div>
<br></div><div>So that brings us back to the case where acivities were previously downloaded and will "disappear", which would be the case for /former/ G1G1 users who update to 8.2, as well as kids in the field.  I'm looking for a concrete answer here on whether or not this is something we do want to fix to make this transition smooth.  Should it get a ticket; should it be a blcoker; should it at least wind up in Scott's "release quality" ticket?</div>
<div><br></div><div>- Eben<br><br></div><div><br><div class="gmail_quote">On Tue, Jul 22, 2008 at 4:58 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div dir="ltr"><div class="Ih2E3d"><span style="border-collapse:collapse">That's still a separate issue than the one I bring up.  They are both important.  My feeling is that the one covered by #7220 is actually less likely in the deployments, because the activities (and, I assume, their defaults file) will almost always be country supplied.  Shall a new ticket for this other edge case be created?<div>

<br></div><div>The only solution I can think of is: make activity in /home/olpc/activities a favorite upon upgrade, in addition to any favorites specified by a new activities.default file, if it exists.  This would prevent activity Foo which the kid downloaded on their own from "disappearing" after the upgrade.</div>

<div><br></div><div>- Eben</div><div><br></div></span><br></div><div><div></div><div class="Wj3C7c"><div class="gmail_quote">On Tue, Jul 22, 2008 at 4:52 PM, C. Scott Ananian <<a href="mailto:cscott@cscott.net" target="_blank">cscott@cscott.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Tue, Jul 22, 2008 at 4:48 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com" target="_blank">eben.eliason@gmail.com</a>> wrote:<br>
> Right, this edge case was brought to my attention by Greg the other day.  It<br>
> will only happen once...in future updates, favorites are preserved.<br>
>  Additionally, in most scenarios, the update will include an "activity pack"<br>
> as well, which includes a country-specified list of default favorites,<br>
> preventing the "empty" Home screen.<br>
> Thus, the only things that disappear are activities which were previously<br>
> installed and are not included in the default favorites list in the update.<br>
>  I'm not sure if we can come up with a simple way to prevent this, or if<br>
> it's worth our time this late in the release cycle for a one-time situation.<br>
<br>
</div>IMO, it is worth our time to ensure smooth upgrades between releases.<br>
If there are no favorites listed when we boot, we should make all the<br>
activities favorites, to preserve the activities the user expects from<br>
the old release.  That is trac #7220.<br>
 --scott<br>
<font color="#888888"><br>
--<br>
 ( <a href="http://cscott.net/" target="_blank">http://cscott.net/</a> )<br>
</font></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>