keith_hodges at yahoo.co.uk
Wed Dec 16 02:24:59 UTC 2009
What we are seeing with these recent discussions of Package management
from Andreas, is essentially an admission that his "new community
development process" really wasn't a process at all, more of an anti-
Lets all hack in an uncontrolled manner, without documenting our
reasons, plans or actions, is not a process, and there is no process
for integration or testing offered either.
6 months later Andreas is still only beginning to think about actual
process issues, like what do do with a package when it has been
removed, and how to manage it.
SUnit has already been conceptually removed (there is a loadable dummy
stub in squeaksource/Testing), and so has Monticello1.5, and Nebraska,
they are currently loadable via package definitions in Sake/Packages,
(with LevelPlayingField for MC).
How did the board manage to hand over the reigns of squeak to someone
who is so ignorant of the actual thinking and progress that had been
made? Think about it where was Andreas in the years 2006-2009 what
active role was he playing in the community? What efforts did he make
to be aware of the progress we had made in that time? I think it is
quite remarkable achievement to go this far backwards in one day.
Considering that I worked on squeak for much of that time, is there no
interest in building on what was achieved?
The package developers lot is one in which the image release teams
keep breaking things from under you. The pharo team is very guilty of
this also. Andreas and Stef work in an image developers paradigm where
they are used to having control of the whole image. So they don't
think of the process in the terms of the package developer, and
everything that I have seen Pharo do, and trunk developers do, is
simply making work for me to keep my packages viable on these moving
Sooner or later you will realize that having a moving target in the
first place is an absolute no no. I manage some 14 loadable packages,
and they are all being subjected to bit rot by release image
developers, this is not helpful, or acceptable. Therefore it will be a
requirement of any actually useful process, to build upon a known
starting points, known by the package developers of the packages you
are loading and testing against.
Given that the original goal of moving squeak forward to a smaller
kernel was stated some 5 years ago, don't you think it is worth
considering this question sooner rather than later? Or even perhaps
first! Anyone can hack an image to smithereens (aka trunk) not
everyone can keep that image stable and tested so that a loadable
package may be loaded in the new image and older images so that you
only need to maintain one release of the loadable package. I don't see
any loadable packages provided by Andreas, or Stef to the community,
not being package developers, they don't work in the package paradigm.
This is the fundamental problem of squeak and pharo, having release
images, and release teams that actively make the package developers
life a pain, because they don't personally test release images against
working derived images. If you want to test against working derived
images, then you have to build those images using loadable packages,
and loadable packages are published to be loadable into a known
starting point. Hence having moving targets as the starting point for
image building is not a viable part of the process.
The "new community development process" is not a viable development
process, unfortunately those pushing this process have destroyed any
semblance of process for managing bugs and fixes against known images
with Mantis, hence my designation of it as an anti-process.
More information about the Squeak-dev