Squid release maintenance, a complaint on how it is being done

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Mon, 10 Jul 2000 00:43:18 +0200

Duane, I'd like to complain a little on how the maintenance of the DEVEL
vs STABLE releases are done.

a) You commit stuff to the STABLE branch without committing them to the
HEAD release.
This is bad from two reasons:
a1) The version most developers work for a long time have bugs which are
known and fixed, increasing the risk that someone else has to rediscover
the same bug and fix it again to be able to continue his work.
a2) The batch merging of the changes from the STABLE branches to the
HEAD version makes history browsing a lot harder. All the history says
is that the change was from the STABLE tree, not what the actual change
is for.

b) The patches on the known-bugs pages often have incorrect hunks in
them, usually from $Id keywords. This confuses people who are trying to
use the patches. Please test patches when making them available, and
remove RCS keywords where applicable (use the -kk option to cvs rdiff)

c) If there has been any critical bug fixes to the STABLE branch, then
please make a new STABLE release within at most a week. I very much
dislike the situation we have had for the last 2 months where the last
official STABLE release has quite critical bugs and must be patched to
be usable.

Regarding the STABLE vs HEAD version I would prefer if all changes was
FIRST committed to the HEAD version, and when proved stable committed to
the relevant STABLE branch(es) and at the same time put on the web site
as a patch for a given problem. If a change is not worth putting on the
known-bugs page then it is not worth putting in the latest STABLE branch
at all.

The snapshot releases is a good initiative, but I don't think snapshots
play well wrt STABLE releases. People should not have to use snapshots
to get a stable Squid release.

I would be happy if you could do these simple steps:

1. Release 2.3.STABLE4 as soon as possible, and maybe stop making
snapshot releases of STABLE branches (see step 3).

2. Port all your changes from the 2.3.STABLE tree to the HEAD version,
preferably with correct log messages if you have time to.

3. In the future, please only put stuff in the STABLE branch which
a) Have been tested on the HEAD version where possible
b) Available as a patch from the known-bugs page (well, the commit has
to go first to be able to make the patch in a clean manner, but you
should get the idea I guess..)

4. When the changes from the 2.3.STABLE branch is merged into HEAD, then
please make a new 2.4.DEVEL release, and announce feature-freeze for
Squid-2.4.

/Henrik
Received on Sun Jul 09 2000 - 16:44:12 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:32 MST