[squeak-dev] Object >> future
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...
More information about the Squeak-dev