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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100515/459da43a/attachment.htm