On 5/15/10 12:43 AM, "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
> 

Great idea.
And I ask again for a .image closer to SqueakCore or with less packages if
was possible.
Count me on for test, build images, etc.

Edgar