Andreas,

Having a package called 'Configurations' in the trunk makes sense for
me. It will contain the configurations for loadable packages which
work for the particular version of the image.

Why not just give it a test drive by working it out for

* Omnibrowser
* Seaside
* Magma
* FFI
* Regex
* ...
* ...

I think we could do this within two weeks.

If the approach fails not much is lost. However currently I do not see
why it should fail.

Really worth trying out and see how it works.

--Hannes

On 5/15/10, Ching de la Serna <ching.dls at gmail.com> wrote:
> terrific!!
>
> On Sat, May 15, 2010 at 11: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
>>
>>
>