How can we improve external package quality?

J J azreal1977 at hotmail.com
Sun May 13 17:27:57 UTC 2007


Yes, this is something I have been thinking about myself lately (and sent 
several mails to the list).  One thing I would say is, we don't need to 
freeze development per se.  When a development branch is frozen to become 
the next version of the main line it simply branches.  So you have 2, and 
sometimes 3 branches at all times:

stable
next stable candidate (once it becomes the next version of stable, the 
candidate branch disappears until the next "freeze")
dev branch

As far as how to keep the dev branch stable, there are different strategies. 
  Some open source projects don't let you check in anything that doesn't 
compile.  We could equate this to having green tests if we wanted, but I 
think we should just try having the branches first and adjust it as we go.


>From: Lex Spoon <lex at lexspoon.org>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: squeak-dev at lists.squeakfoundation.org
>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
>
>
>

_________________________________________________________________
Make every IM count. Download Messenger and join the i’m Initiative now. 
It’s free. http://im.live.com/messenger/im/home/?source=TAGHM_MAY07




More information about the Squeak-dev mailing list