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