[sugar] Bundle .info change

[Dan Williams]

On Tue, 2006-12-19 at 11:35 -0800, Yoshiki Ohshima wrote:
>   Marco,
> 
> > Well, given the current state of the code, it's hard to plan changes to 
> > give activity authors a few days to update their code. This particular 
> > change happened because of some refactoring I needed to be able to keep 
> > working on the journal UI.
> 
>   For what Bert asked, a little help from the framework *might* speed
> up the entire development process overall.
> 
> > I think this kind of breakage (etoys not starting) in the daily builds 
> > is acceptable. I'm doing what I can to avoid but I don't want to slow 
> > down development because of it. Sugar is in alpha state, it's not yet 
> > the time to pretend fully stable builds everyday.
> 
>   Such a change doesn't necessarily have to be noticed in advance, but
> I wish if there were a better mean to communicate with people outside
> Massachusetts on the kinds of changes to the system.  Each sub-system
> is depending on bunch of libraries and other components, so some
> seemingly innocent changes by somebody may affect somebody else's
> component through the dependency chain.  You said that people in
> community should test their stuff daily, but testing without knowning
> what has changed can lose the focus.
> 
>   (As a starter), what if I ask you to generate the output from
> "ls -lR" and put them in the build<nnn> directories on the server so that
> I can just get the diff between them?  In this way I will be able to
> see what kind of problems I should be cautious (for some extent).
> Removing libGL.so would have been spotted easier, for example with
> this mechanism.

Most of this can be achieved already.  Grab the build logs, and diff
them.  You'll see additions/removals from the package lists, which will
alert you to issues like the libGL one.  A reasonable suggestion is a
per-build mail sent to devel at laptop with package additions/removals.  We
should also have somewhere the hard list of libraries that, at a
minimum, we expect to ship.  Anything not on that list could not be
counted on to be in the images, even _if_ it did slip into a few of them
at various points.  Examples: libGL, perl, emacs, vi, etc.

Ideally, we would have developed the platform for the past 3 years and,
this past summer, rolled it out with a stability guarantee and
occasional bugfixes.  But that's not the case, and the platform is being
developed _in parallel_ with the activities that are supposed to run on
it.  That's not particularly easy for anyone, but the alternative is for
activity developers to wait until next year when OLPC comes out, and
_then_ start developing.  If people want to get a head-start, then there
is going to be a certain amount of flux and pain; that's the choice.

OLPC also needs the software to be successful, and to that end, shafting
activity developers makes no sense.  We need to do better here.  But
those of you developing for the platform already have much more input
and much more technical influence and involvement in the direction OLPC
takes than if we dropped a ready made platform over the wall.

Dan

> > Clearly if there will be major changes, this will be done more 
> > carefully. But this was only a one liner, trivial change.
> 
>   That was a one liner was Bert's point, too^^;
> 
>   Thank you!
> 
> -- Yoshiki
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar