On Oct 13, 2005, at 10:32 AM, Daniel Vainsencher wrote:

> Note that the work needed to be able to share packages is exactly  
> the work required to make the update stream work - create a series  
> of loadable package versions that get (any image) from here to there.
>
> This is what makes the whole "images vs updates" thread pretty much  
> bogus in my eyes. If we stop doing this work for some package, and  
> just patch things up, we will probably never share that code with  
> any other image-lines that want to keep their own images.

We don't yet have an update script that can take an arbitrary image  
and load Traits into it.  Does that mean it's impossible to share  
Traits with any image line other than the one it was developed in?

Of course not.  There are manual ways for an experienced developer to  
integrate Traits into whatever image I give them.  There may be  
challenges unique to any particular image, but they would certainly  
be solvable.  And once solved, it's very likely that any further  
updates to Traits - loading new versions of the various Traits  
packages - would be much easier.  Maybe still a manual process in  
some cases, but easy enough that it could be done at regular  
intervals.  And anyone who was a client of that image line would get  
that integration for free, by downloading the newly integrated image.

Capturing easy integrations with scripts is easy.  Capturing hard  
integrations with images is easy.  Capturing hard integrations with  
scripts is hard.  If we bias towards the first two rather than the  
third, we have more energy for writing interesting code to  
integrate.  What's bogus about that?

I enjoy solving hard problems, but not for their own sake.  If I can  
see a way to be lazy and avoid them, I take it every time...

Avi