From owner-freebsd-stable  Tue Jun 11 22:38:52 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA29655
          for stable-outgoing; Tue, 11 Jun 1996 22:38:52 -0700 (PDT)
Received: from oyster.vast.unsw.edu.au (oyster.vast.unsw.edu.au [149.171.224.32])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA29650
          for <freebsd-stable@freebsd.org>; Tue, 11 Jun 1996 22:38:48 -0700 (PDT)
Received: from conch.vast.unsw.edu.au (conch [149.171.224.3]) by oyster.vast.unsw.edu.au (8.7.5/8.7.3) with ESMTP id PAA27705 for <freebsd-stable@freebsd.org>; Wed, 12 Jun 1996 15:38:08 +1000 (EST)
Received: from spindle (spindle.vast.unsw.edu.au [149.171.224.45]) by conch.vast.unsw.edu.au (8.7.5/8.7.3) with SMTP id PAA14853 for <freebsd-stable@freebsd.org>; Wed, 12 Jun 1996 15:38:43 +1000 (EST)
Received: by spindle (5.0/client-1.3)
	id AA22769; Wed, 12 Jun 1996 15:38:42 +1000
Date: Wed, 12 Jun 1996 15:38:41 +1000 (EST)
From: Julian Jenkins <julianj@vast.unsw.edu.au>
X-Sender: julianj@spindle
To: FreeBSD Stable Users <freebsd-stable@freebsd.org>
Subject: Re: The -stable problem: my view 
In-Reply-To: <199606080419.WAA02553@rocky.sri.MT.net>
Message-Id: <Pine.SOL.3.91.960612151120.22532A-100000@spindle>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-stable@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, 7 Jun 1996, Nate Williams wrote:

> > We need a new model. One that keeps the quality high and one
> > that doesn't prevent me from doing new development.
> 
> Do you have any suggestions?  Would creating a new 'stable' tree today
> be even remotely acceptable?

I have a suggestion for a system that could solve at least part of the 
problems.

Every 6 months or so, at a time when -current is fairly stable, a new 
branch should be created that is destined to become the next release. 
After a period of bugfixes, etc (6 months?) this becomes the next release.

At the time that this branch is now declared the stable branch and no 
changes other than bugfixes are welcome in that tree. The old stable 
branch can be discarded at this time. At this point the core team and anybody
else can disown it and let those who use it perform any neccesacary 
managment. There may be a market for the old branch on CD at its final 
state for those who are excessively(sp?) paranoid or feel that the new 
stable is not yet as good as the last.

The time of the new release is probably also a good time for a new branch 
to be created for the next release and the whole process started over.

All people making changes to the release and stable branches should be 
encoraged to determine if it is appropriate to make them to the current 
branch as well.

Rules for committing into the release and stable branches should be 
devised. These would probable be along the lines of only bugfixes are 
accepted into stable (people developing new features should be putting 
them in current and not wasting their time on stable), and features may 
be accepted into the release branch only if there is a very good reason 
for doing so.

This scheme has the advantage that there is always a branch that is more 
stable than the last release. However this requires three branches which may 
make it impractical.

Julian
kaveman@magna.com.au