[squeak-dev] Object >> future

keith keith_hodges at yahoo.co.uk
Wed Mar 10 20:07:27 UTC 2010

> Why do you feel that you are entitled to have me make this available  
> in whichever image you've decided to use?  I have not heard users of  
> Cuis, Pharo, or Cobalt ask for this functionality.  Why should I  
> spend my limited spare time creating and maintaining loadable  
> packages for these?

Because if you had thought about the problem first, in the light of  
the fact that we are living in a multi-fork world, then your  
innovation could have been designed to be potentially loadable in all  
forks from the start, and derived images (with tool support to help  
you with building and testing it in all targets) , and you could have  
used 3.10.2 as one example use case of the integration of that  
innovation, for others to copy.

This is what us package developers have been doing for years. If I can  
do it for Rio, and Logging, you can do it for your stuff too.

The crime is that the process you are using, "trunk" causes you by  
default to think and act as if you are in a one fork moving target  
world, and to think in a "I will just throw this in for good measure"  

The end result being that your efforts integrating it into trunk will  
inevitably have to be repeated by others. However those others do not  
have your knowledge and will all have to reverse engineer everything  
you did and guess at all of your design decisions and the fixes you  
had to add to trunk to accommodate.

This means that the net result for the community is that you, in your  
attempt to provide a simple new feature just for your own pleasure,  
have actually generated work for other people, and this is what i  
think can be improved. What is needed is some form of knowledge  
capture on the way.

I am not saying you have to package it as loadable for everyone, but  
it would be helped by a process which identifies your work as a  
discrete separate lump, rather than mixing it in with everything else.

If you had simply developed it for 3.10.2 rather than trunk, that  
would have done the trick.

In the "grow" scheme I have 4 or 5 kernel innovations on the go. But  
they are all being developed relative to the base-dev image. This  
keeps things uncluttered. If these innovations interfere unduely with  
one another then this is a clue that I need to improve their modularity.

It is then trivial to generate a build with all 5 innovations loaded,  
even though it may not work immediately.

If one of the five innovations loads in cuis-base-dev, then the  
knowledge I need to make that happen is captured in the fixes that go  
into the cuis-base-dev package. When I load it into pharo, I port just  
that knowledge, into the pharo-base-dev package. As the base-dev  
images get more api commonality. Then when it comes to porting the  
other 4 innovations, to the other forks it gets easier.


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

More information about the Squeak-dev mailing list