How can we improve external package quality?

Lex Spoon lex at lexspoon.org
Sun May 13 10:58:28 UTC 2007


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





More information about the Squeak-dev mailing list