[squeak-dev] Community Supported Packages
Dale Henrichs
dale.henrichs at gemstone.com
Sat May 15 18:56:50 UTC 2010
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".
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 ...
Dale
----- "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
More information about the Squeak-dev
mailing list
|