How can we improve external package quality?

>From: Lex Spoon <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: [hidden email]
>Subject: How can we improve external package quality?
>Date: 13 May 2007 12:58:28 +0200
>
>Hey, guys, Ralph Johnson recently reported that most external packages
>in the 3.10 development universe have failing tests.  Since 3.10 will
>have all-passing tests in the core image, this is a good time to think
>about moving in that direction for external packages, too.
>
>The precise process we should use is something that needs to be felt
>out over time.  We are going to have to find something that works for
>our own quirky but wonderful community.
>
>
>Let me describe my current thoughts, and then leave it up to the group
>to suggest alternatives.  Ultimately, we will need to agree on
>something, and so leadership has a role.  We should have something
>like a release team, which is maybe the same as the current release
>team, which manages external packages.
>
>
>Generally, it seems good to have both stable releases and development
>streams.  A stable release is a set of packages that are of
>exceptional quality and which all work together.  A development stream
>has more recent package, though at lower quality, and is under
>constant improvement by the community.
>
>Periodically, a stable release can be created out of a development
>stream by chilling the development stream ever further until it is
>completely frozen.  At that point you clone off a stable release, and
>then unthaw the development stream for further work.
>
>So far, there have been two stable releases made mostly by myself.
>For the forseable future, that kind of approach seems fine.  One or a
>few people go through the development stream, run the tests, check the
>bug logs, etc., and pick some of them as the stable release.  If they
>have the spare energy, they can even post release candidates for
>people to play with, before doing the true release.
>
>
>The more interesting question is how to handle development streams.
>This is getting long, so let me just mention two issues.
>
>First, it is nice to spread out maintainance of individual packages as
>much as possible.  It seems impractical, to me, to have the
>stable-release makers constantly update all packages in the
>development stream.  Further, the individual maintainers tend to have
>have a lot of pride invested in the code they are sharing publicly.
>they have every motivation to fix up their packages, if only we let
>them.
>
>
>Second, so far, based on Ralph's observations, we seem to get poor
>quality in the development stream.  So, maybe we should restrict
>posting in some way, even during evelopment streams.
>
>That's where I get vague.  How, exactly, could we restrict access to a
>development universe, so that individual maintainers do most of the
>work, but there is still *some* level of quality control?
>
>Does anyone have ideas here?  This is something we need to figure out
>for our community and come together on.
>
>Lex
>
>
>