On Thu, Jul 17, 2008 at 5:11 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > Actually, I have one more concern. It seems to me we might be better off > checking against a hash of the file, instead of a timestamp. We don't want > to continually merge new favorites with every OS update, but that's exactly > what we'll do if we only check the timestamp on the favorites.default file, > right? By checking a hash, we ensure that someone (either us, by "shipping" > a new favorites.default, or the country, via a customization key) intended a > new merge to happen.
Well, what if the country removed an activity because it's no longer shipped, do we still want to add the rest of the activities that the user unfavorited? I'm not sure it's worth going to such details right now, even more when laptops will be updated at most twice per year. Also, at this point in the release, pushing patches is quite expensive. But enter a ticket if you really want this in a future release. Tomeu > On Thu, Jul 17, 2008 at 11:04 AM, Eben Eliason <[EMAIL PROTECTED]> > wrote: >> >> I see. Yes, I think that works. >> - Eben >> >> On Thu, Jul 17, 2008 at 10:58 AM, Tomeu Vizoso <[EMAIL PROTECTED]> >> wrote: >>> >>> On Thu, Jul 17, 2008 at 4:50 PM, Eben Eliason <[EMAIL PROTECTED]> >>> wrote: >>> > >>> > >>> > On Thu, Jul 17, 2008 at 5:31 AM, Tomeu Vizoso <[EMAIL PROTECTED]> >>> > wrote: >>> >> >>> >> On Thu, Jul 17, 2008 at 3:19 AM, Eben Eliason <[EMAIL PROTECTED]> >>> >> wrote: >>> >> > Yeah, I'm not sure that this is expected behavior (I would expect >>> >> > not). >>> >> > The >>> >> > intent is that a "customization" upgrade would allow additive >>> >> > changes to >>> >> > the >>> >> > favorites ring, for instance to allow a school to ensure that every >>> >> > kid >>> >> > has >>> >> > brand new activity X in the ring on the first day of class (if the >>> >> > kids >>> >> > later remove it, that's up to them, of course). The question, then, >>> >> > is >>> >> > if/why installing that RPM behaved in the manner of a customization >>> >> > instead >>> >> > of a basic software update. >>> >> > Tomeu, do you know how this is expected to work? >>> >> >>> >> When kids update to a version that has the notion of favorites, we >>> >> don't want to show the favorites screen empty. That's why we added >>> >> code for adding the activities mentioned in activities.default. >>> > >>> > I'm OK with this if it's a one-time change. In other words, it should >>> > check >>> > for an empty favorites list and apply the defaults if none exist. >>> > >>> >> >>> >> Also, when you update to a newer version, favorites.default might >>> >> change so we merge it again with the users favorites. We don't know if >>> >> an activity present in activities.default but not in the favorites was >>> >> removed by the user or added by the school/deployer. >>> > >>> > Well, it depends on the use case. Is editing favorites.default the >>> > intended >>> > way for a country or school to manage updates? If so, then I suppose >>> > that >>> > this is correct. If not, then we should really only be setting the >>> > favorites from the default file when no favorites are set at all >>> > (should >>> > only happen once), and otherwise do a merge from a favorites list on a >>> > customization key instead. >>> >>> What I understood is that the customization key would install some >>> activities and a activities.default file. When Sugar starts up, it >>> checks if activities.default has changed since last time we merged it, >>> and if so, we merge it again. Is this right? >>> >>> Regards, >>> >>> Tomeu >> > > _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
