2010/3/10 keith <keith_hodges at yahoo.co.uk>:
> Josh,
> 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 monticello.
> 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).
> regards
> Keith
> ===
> "Branching is the new Forking"
>
>

Keith,
Unfortunately, this change is unlikely to be portable because it
overrides internal Parser/Compiler methods.
Due to this, all the noble features that you wish are void.
The job has to be done N times for N images, independently of the tool
used, this has nothing to do with MC.

You cannot ask each guy to provide an N-images compatible change, or
set of changes, This is not practicle, and simply won't work. With
such a policy, progress will soon stop.
Pharoers program for Pharo, squeakers for trunk, etc...
Then, it does not prevent to exchange ideas and solutions, and it's
better if we exchange before programming. I for sure will support
unification on some Kernel features. But then, we can diverge,or what
exactly is the point of having forks ?

Nicolas