How can we improve external package quality?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How can we improve external package quality?

Lex Spoon-3
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



Reply | Threaded
Open this post in threaded view
|

RE: How can we improve external package quality?

J J-6
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 <[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
>
>
>

_________________________________________________________________
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