[squeak-dev] Object >> future

keith keith_hodges at yahoo.co.uk
Wed Mar 10 11:14:49 UTC 2010


so now we have a feature in trunk called "future". I don't know if I  
want it in my version of Cuis or not. I am not even sure what this  
feature consists of, in that I cant see what its boundaries are.  
However if I do I will want it to be a load-able extra, because some  
package I want to load may need it.

As a simpler example, take Mutex. Cuis doesnt have it, Magma uses it.  
It is a relatively isolated piece of functionality, it doesn't need to  
be managed inside the image, it can easily be a load-able feature.

Can you answer if you will, how you have packaged up this "future"  
innovation so that it would be useful to me?

If your answer is that you committed it to trunk, and I am expected to  
harvest it from trunk, I think you can forget it.

If your answer is that it is in Monticello inbox, then how can I get  
the most current version, surely the inbox version will have been  
tweaked in the image. And cuis being a kernel image doesn't have  

Previously you said: "if we can achieve some of your goals without  
sacrificing the benefits of the new process"

Hopefully this will help you to see that trunk is not really process  
offering any benefits at all. As far as I can see it is simply  
promoting sloppy work practices, where everything new you can think of  
gets thrown into the soup of a monolithic image, and now everyone can  
join in throwing stuff at the future (if you excuse the pun) image.

When I use the "grow" process I am now running and developing the same  
code, (even kernel level code that would break trunk) in all forks  
simultaneously. Every innovation or which is managed as a loadable  
extra, becomes a potential point of commonality between existing  
forks. The fact that trunk is not managing its features outside of the  
image, is a disaster. Heck you haven't even split System up (yet).



"Branching is the new Forking"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100310/55675c0a/attachment.htm

More information about the Squeak-dev mailing list