[squeak-dev] The Pillars of Squeak

Keith Hodges keith_hodges at yahoo.co.uk
Mon Jul 6 18:42:33 UTC 2009


Dear All,

I am not and never intended to compete with Andreas. I most certainly do
not have time or energy right now.

Andreas could have come to me with his ideas in the first place, and
integrated them into the existing philosophy and  process rather than
replacing the process, and attempting to integrate my tools into a new
process for which they were not intended. He could quite easily have
picked up the ball and run with it by loading squeaksource/Tasks and
reviewing class ReleaseAfterSqueak310 and looked at it tried it out and
refined it.

As far as I know I am the only person who has been motivated to get some
significant commonality going between existing forks, and we have had
one major success so far, with Gjallar being able to move from 3.8 to
3.10 due to its use of Installer scripts.

I am going to let you lot get on with whatever you want to do because
Andreas is not going to submit to my overall vision anyway. Either he
thinks my ideas are worth using or not. Since my main idea was that of a
philosophy embodied in a rigid repeated automated process which he has
summarily replaced with a relatively haphazard uncontrolled and
unplanned process, it appears not. I believe that ultimately my ideas
will stand or fall on their own merit, and I will just have to be more
patient.

I have no quibble with the idea of using a common repositories, for
externally managed projects, and the plan was to move certain components
of the kernel out into externally shared (or stolen/acquired from pharo)
packages anyway. e.g. Network, Collections etc.

I maintain that the image itself (or the repository representing it,
otherwise known as "trunk") should only be touched by completed "grand
refactorings" that are at the point of integration, and this integration
should be effected by an automatic build task every day/week into a
separate "unstable" image until deemed ready.

I believe that if all the maintainers of all the forks, adopted this
approach, even in part, then "ready to integrate chunks" would be more
readily exchanged and shared among forks.

I resist strongly the idea that all kernel packages be made open access
for people to simultaneously apply multiple incomplete innovations and
refactorings that have not been subjected in their complete form to peer
review or test in a publicly available "unstable" image.

At present I don't have time to compete, or to build something and say -
there you go my ideas was better after all.

After you have mangled the image about a bit, I will take another look
at the situation when I have time. For the moment my future work on Bob,
will strictly be work that I need for my commercial projects and
amusement. All the sources etc are available for you to play with if you
want to. I might be back around October.

have fun

Keith





More information about the Squeak-dev mailing list