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- 
process.

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  
targets.

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.

Keith