New subject: Community Supported Packages

15 May 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@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

Re: [squeak-dev] Community Supported Packages