[squeak-dev] I Want Keith...

keith keith_hodges at yahoo.co.uk
Wed Feb 17 03:32:46 UTC 2010

> BTW, I was surprised to see that Matthew feels that you and he "set  
> Squeak back 2 years... and caused the Pharo split".  I certainly  
> hope that he's not beating himself up about it as much as that quote  
> suggests.

It's a totally ridiculous notion.

The pharo split was caused by Stef and Marcus knowing that they could  
never work in the political environment that is squeak-dev and achieve  
the goals that they wanted. Much of this impression was gained by  
their experiences working on 3.9 during which certain board members  
were among many who gave them a particularly hard time.

It turns out that they were entirely justified to fork on political  
grounds. However on a technical basis I was begging them to work with  
a collaborative process, rather than the "we control everything"  
process they adopted. Fundamentally every contribution to pharo is  
also made to a moving target and potentially makes work for anyone who  
wants to keep up, or port innovations to or from pharo.

As a package writer and maintainer, the only actual progress I have  
seen from pharo is a bunch of emails from otherwise happy customers  
saying "this doesn't work in pharo any more". From the point of view  
of a package maintainer the best progress would be to not change  
anything, just fix broken things.

As for setting squeak back 2 years, it depends what you want to  
achieve. If you wanted to build a production image, that would be  
promised to get more stable over time, we made a lot of progress, and  
promised more because our process was a regular cycle, loading fixes  
from mantis, and integrating the latest packages, fixes tested against  
an existing release image.

What particularly annoyed me about the boards actions was the fact  
that mantis is no longer tracking against 3.10.2. This is the biggest  
recent loss for the community, it means that the community has given  
up, (without thinking or discussing) the idea of formally supporting  
existing released images, and this is a HUGE step backwards. A fix on  
mantis which loads into and is tested against trunk is of no use to  
me, I maintain that all fixes should be published to mantis against  
the released image, and that trunk dilutes this in favour of some new  
future release in which all will be fixed if you wait a year or two.

We made the most progress by identifying the primary problem 4 years  
ago, the problem is that of being bottlenecked behind a single  
maintainer or elite group who develops stuff for their fork only in  
their repository that you or I as a developer of commercial code have  
no control over at all. This lack of control is made worse by the fact  
that the image I will be given that has fixes I need in it, will take  
over a year to arrive and I will have no say or control over what it  
contains. This technical uncertainty is ony compounded by the  
political uncertainty that any plans I make for the future of my  
commercial project are potentially overturned any time some new person  
is elected to the board.

As a commercial developer squeak used to be a pain in the neck where  
you had to manually track down the dependencies of every package you  
wanted to load and manually painstakingly load them, only to hit the  
changes file limit a few months later, and be forced to start all over  
again. We did make a lot of progress, for such commercial developers,  
and we will continue to do so.

Watch this space. - Manifesto coming up.


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

More information about the Squeak-dev mailing list