Bob Arning  <arning at charm.net>  wrote...

>My dislike for the packagizing effort stems from:
>- it has a _very_ low signal-to-noise ratio
>- it does not solve any problem that I face now or forsee facing in the near future
>- I think that it will reduce the shared experience that has contributed to the growth of Squeak to this point

I don't see why this has to be...

Good packaging *should* make it easier for anyone to put out a new enhancement to Squeak.  It should make it easier for people to try out, and it should make it easier for to ensure that it works in different versions of the system.  If it becomes part of some jumbo image, it should make it easier for people to jettison if they don't want it.

This would appear to enhance the ease of sharing, and hence the motivation to contribute.  I don't understand the downside.

Unless you're comparing it to a world in which everyone operates with the "latest and greatest jumbo image".  Even then, I don't seeany conflict.  While I'm sort of enjoying life on the sidelines right now, it always felt to me that the big picture in the package world supported several classic patterns of use:

	Latest and Greatest Jumbo image
	Includes just about everything that is stable, plus a couple of interesting
	projects that are alpha and may not survive ultimately.
	This is pretty much what SqC used to release.

	Simple Development image
	Complete enough to give full development support
	but lean enough that you could feel proud to teach a class from it.
	This is what the 2.1 Mini.image was (thought in the days of MVC)

	Minimal Kernel
	This one is hard to generalize because different people
	want different stuff discarded.

I have always felt that it made sense to release both a Simple Development image and a Jumbo image.  The promise of the packages work was to offer pretty much of a check-box control panel that could allow you to import or jettison anything between these three levels -- a great leap forward over the old discardX methods that leave dangling code references all over the place, and don't work from one release to the next.

So I see only upsides in the *framework*.

I have a feeling that the underlying issue is a bit more about leadership and how we choose direction.  In the days of SqC it was pretty much of a (hopefully benevolent) dictatorship.  This worked because the steady state community agreed with most of the direction -- by definition:  those who didn't left the community.

It may be that there's a need to revisit some of the basic charter/vision issues, what with changes in the community, technology, leadership, etc.  To the extent that this was successful, it might give the guides some useful guidance, and the community some useful assurance that there is a shared script where most major concerns are addressed.  The idea is to separate the process of agreeing on a vision and plan from that of realizing the plan, and thus to reduce the chances of idealogical tension frustration in the process of practical progress.

This kind of realignment and rededication has to happen regularly (like yearly) in any evolving project such as this, but  the responsibility for it is being allowed to fall back on the entire community now for the first time.

I realize this is SqF territory, but it's just my reflection on what has spilled out into general discussion in the last day or two.

	- Dan