On 5/15/2010 11:56 AM, Dale Henrichs wrote:
> Andreas,
>
> The package of Configurations sounds like a very good way to clearly identify (and manage) the set of supported configurations.
>
> As I think about, you may want to a use a different naming convention for the configurations so that there is a reduced chance of the supported configuration clashing with the names of configurations loaded from the "wild".

That's good advice. Anyone having opinions about that? I'm thinking that 
perhaps <package>Installer might be a good choice, i.e.,

	FFIInstaller load. "Loads the latest FFI"
	OmniBrowserInstaller load: 'default'. "Loads the default group"
	Seaside28Installer load: 'All'. "Loads everything"


> Regarding tools, I am trying to stay out of the tool business for Metacello. Not that tools aren't needed but that maintaining Metacello is a big enough chunk to bite off without having to get into the tools business:)
>
> With that said I am more than willing to expand the API as needed to support the development of tools ...

I'm hoping to keep it simple for starters - what I really want is 
something roughly resembling the SqueakMap UI, that is a categorized 
list (based on system categories for the installers) that can be 
searched and have a one-page description (perhaps listing various load 
options). Shouldn't be very hard to mock up.

Cheers,
   - Andreas

> ----- "Andreas Raab"<andreas.raab at gmx.de>  wrote:
>
> | Folks -
> |
> | I've finally gotten some thoughts together for how to address the
> | 'package issues' in Squeak. This is going to take a while so I
> | apologize
> | beforehand for the length of this message :-)
> |
> | First, let's talk about the goals. What I'm trying to achieve is
> | basically to blur the line between what is 'in' the image and what is
> |
> | 'out' of the image. What I'm trying to achieve is to enable people who
> |
> | write applications and libraries for Squeak to be seen as direct
> | contributors to Squeak. What I'm trying to achieve is to drastically
> | grow Squeak by being much more inclusive while at the same time
> | drastically shrinking it by having many fewer packages 'preloaded'.
> |
> | How can we do this? Over the last months I've spent some time looking
> | at
> | options for package management. I don't really like any of the
> | available
> | options but since I'm not going to write something new, I've
> | concentrated on the one choice that appears to be actively supported -
> |
> | Metacello. It has its weaknesses but contrary to all the other options
> |
> | it's the one choice that is being supported and I appreciate that.
> |
> | While looking into Metacello I also spent some time at the Pharo
> | Metacello repository on Squeaksource. There are many interesting
> | things
> | to be said about it, both good and bad. Good things about it are that
> |
> | it's community maintained. Everyone can update everyone else's
> | contributions and although that's not generally done, it offers a
> | community approach to making sure things work. Something that for
> | example both Universes and Squeakmap lack completely. What's
> | problematic
> | about the repository on the other hand is that for one thing one needs
> |
> | to unconditionally trust the code even before one has even decided to
> |
> | install it (this by far my biggest complaint about Metacello). Also, I
> |
> | don't think that a single repository is a feasible option in the long
> |
> | term - it seems to me that supporting the cross-product of image and
> | package versions is going to be problematic before too long. And of
> | course browsing repositories with several dozen of packages to find
> | what
> | you need isn't exactly fun either.
> |
> | However, the problems can be turned on their head, and that's actually
> |
> | pretty insightful. Here's the basic idea: What if, instead of having a
> |
> | single repository for all image versions with separate packages for
> | each
> | config, we would instead have a single package simply called
> | Configurations in the trunk?
> |
> | That Configurations package would contain all the "supported"
> | configurations for Squeak (I'll get to that in a minute). The package
> |
> | would be community-maintained, just like any other package in trunk
> | development process. This addresses the trust issues with Metacello,
> | since the package has the same level of trust that all the other
> | packages in a Squeak release have; it has been developed using the
> | same
> | principles.
> |
> | What that gives us is a mechanism by which we suddenly can include
> | Omnibrowser, Seaside, Magma, FFI and anything else people can come up
> |
> | with in Squeak without having to preload it in the shipping image.
> | What
> | it also means is that we can start removing packages from the image,
> | replacing them with the proper configurations for how to load them
> | back.
> | What it means is that somebody with a new application (be that
> | Stephane's Muo app, Hillaire's Dr. Geo, or Josh's OpenCL demo) can ask
> |
> | for the configuration to be part of the next Squeak release, thereby
> | contributing *directly* to that Squeak version.
> |
> | Most importantly, however, is that we as the community can decide what
> |
> | we feel we want to support and what not. By being explicit about the
> | 'house rules' we can make sure that the model is sustainable moving
> | forward.
> |
> | To do that, I'm proposing to create a status of "Community Supported
> | Package" in Squeak. What is that? A community supported package is a
> | piece of software where we feel this is an important/interesting/novel
> |
> | package that should ship with this Squeak version. A community
> | supported
> | package can be loaded in a 'one-click' process directly from within
> | the
> | image. A community supported package is a package where we provide
> | assurance that the package has been tested for this release.
> |
> | However, that status does not come for free. In return for achieving
> | this status, the software needs follow the rules for community
> | supported
> | packages, which (at least) should include the following:
> |
> | * No conflicts. Neither class names nor -override categories. The
> | rationale is that all community supported packages can be loaded
> | together without creating conflicts.
> |
> | * Tests mandatory. A community supported package MUST have tests. The
> |
> | rationale is that since we provide the guarantee that the package has
> |
> | been tested, we need to ensure that testing can be automated to the
> | maximum extent possible. It doesn't mean 100% coverage but *some*
> | meaningful set of tests need to be provided or else we can't say if we
> |
> | broke it in the latest update.
> |
> | There may be some other guidelines that we may want to establish but
> | I'm
> | trying to keep things simple and only the above two are truly crucial
> | -
> | what they allow is to ensure that during ongoing trunk development we
> |
> | will always be able to load all supported packages, run the tests and
> |
> | see if we broke something horribly.
> |
> | So the goal of the process is that if we do this right, we should be
> | able to tell how good (or how bad) a shape we're in regarding the
> | supported packages when we get to ship date. We should be able to
> | encourage people who write libraries or apps with, for, and in Squeak,
> |
> | to contribute directly to the next release by providing a
> | configuration,
> | their code, and the tests so that we can keep things running. In
> | return,
> | we'll help with porting, provide backwards compatibility as required
> | etc.
> |
> | Code that we want to move out of the default image would be moved into
> | a
> | configuration so people can load it if desired, and it remains a part
> | of
> | Squeak instead of rotting away. Since the Configuration package is
> | small
> | and has no dependencies, there's no problem to include that in
> | core/basic images and allow people to tailor custom images from
> | there.
> |
> | Concretely, I'm seeing the following steps as necessary:
> |
> | 1. Establish the status and the rules for "Community Supported
> | Packages".
> |
> | 2. Create the "Configurations" package and start populating it with
> | some
> | examples (Omnibrowser, FFI, Magma ...) to see how that 'feels' like.
> |
> | 3. Encourage people to bring their packages up to 'community
> | standards'
> | and include them in the Configurations.
> |
> |  From here, there are a few more things that we should do before we
> | can
> | ship the next Squeak version:
> |
> | 4. Provide a better installer than these awful doIts for Metacallo.
> |
> | 5. Establish a test server to automatically verify the community
> | standards for supported packages (i.e., load packages randomly, ensure
> |
> | no conflicts, run tests, report results).
> |
> | At this point, there is another clearly defined way to contribute to
> | Squeak even if you're not a core developer: Develop your software,
> | provide a configuration, ensure your software adheres to the community
> |
> | standards. That's it. You've just made the next Squeak release a
> | little
> | better :-)
> |
> | Cheers,
> |    - Andreas
>
>