On Jan 25, 2010, at 8:31 AM, keith wrote:

>> 
>> ... and thanks again.
>> 
>> One thing that strikes me about this is that it is agnostic about how the fixed-point images are built.
> 
> The fixed point images need to be built, by a process which applies to the previous fixed point.
> 
> So that a fork which was made from the previous fixed point, can cherry pick from, and apply that process too.
> 
> The more that separate forks pick ideas from other forks, the more they have in common.
> 
> Basically to use the knowledge that is in trunk, you will have to analyse it and sort it into separate useful innovations and ideas, and publish them as separate changesets.
> 
> Ironically, most of those innovations could have started of as separate changesets in the first place. Am I making sense?


Yes, I think so.

I think that the problem here is that we're talking about at least two things.  One is the ability to use improvements to one fork in another fork.  Another is the ability to move an existing application code-base forward to the newest fixed-point release.

I'm not saying anything at all about the first one here.  In particular, I'm not arguing that the process used to create images doesn't matter for cherry-picking packages between images.

I contend that for the latter, it does not matter how the fixed-point image was created, just that you continuously build and test your application against frequent releases, and work with the community to quickly fix any compatibility issues that arise.  Isn't this true?

Thanks,
Josh





> 
> 
> Keith
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100125/2df1e0fd/attachment.htm