terrific!!<br><br><div class="gmail_quote">On Sat, May 15, 2010 at 11:43 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Folks -<br>
<br>
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 :-)<br>
<br>
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'.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
* No conflicts. Neither class names nor -override categories. The rationale is that all community supported packages can be loaded together without creating conflicts.<br>
<br>
* 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Concretely, I'm seeing the following steps as necessary:<br>
<br>
1. Establish the status and the rules for "Community Supported Packages".<br>
<br>
2. Create the "Configurations" package and start populating it with some examples (Omnibrowser, FFI, Magma ...) to see how that 'feels' like.<br>
<br>
3. Encourage people to bring their packages up to 'community standards' and include them in the Configurations.<br>
<br>
>From here, there are a few more things that we should do before we can ship the next Squeak version:<br>
<br>
4. Provide a better installer than these awful doIts for Metacallo.<br>
<br>
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).<br>
<br>
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 :-)<br>
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
</font></blockquote></div><br>