From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/32671
Path: main.gmane.org!not-for-mail
From: smd@ebone.net (Sean Doran)
Newsgroups: gmane.emacs.gnus.general
Subject: Re: Oort Gnus branch
Date: Sun,  1 Oct 2000 18:44:22 +0200 (CEST)
Sender: owner-ding@hpc.uh.edu
Message-ID: <20001001164422.AD94B88F@sean.ebone.net>
NNTP-Posting-Host: coloc-standby.netfonds.no
X-Trace: main.gmane.org 1035168916 21103 80.91.224.250 (21 Oct 2002 02:55:16 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Mon, 21 Oct 2002 02:55:16 +0000 (UTC)
Cc: ding@gnus.org
Return-Path: <owner-ding@hpc.uh.edu>
Original-Received: from fisher.math.uh.edu (fisher.math.uh.edu [129.7.128.35])
	by mailhost.sclp.com (Postfix) with ESMTP id F4215D051E
	for <jason@mailhost.sclp.com>; Sun,  1 Oct 2000 12:44:56 -0400 (EDT)
Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5])
	by fisher.math.uh.edu (8.9.1/8.9.1) with ESMTP id LAC05587;
	Sun, 1 Oct 2000 11:44:43 -0500 (CDT)
Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 01 Oct 2000 11:44:06 -0500 (CDT)
Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged))
	by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id LAA26387
	for <ding@hpc.uh.edu>; Sun, 1 Oct 2000 11:43:57 -0500 (CDT)
Original-Received: from sean.ebone.net (sean.ebone.net [195.158.227.211])
	by mailhost.sclp.com (Postfix) with ESMTP id 834B7D051E
	for <ding@gnus.org>; Sun,  1 Oct 2000 12:44:23 -0400 (EDT)
Original-Received: by sean.ebone.net (Postfix, from userid 1113)
	id AD94B88F; Sun,  1 Oct 2000 18:44:22 +0200 (CEST)
Original-To: Kai.Grossjohann@CS.Uni-Dortmund.DE, zsh@cs.rochester.edu
Precedence: list
X-Majordomo: 1.94.jlt7
Xref: main.gmane.org gmane.emacs.gnus.general:32671
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:32671


| Another thought is that maybe we would like to do it like Emacs does
| it.  So, how does Emacs handle the branches?

NetBSD creates a tag to represent a forthcoming release; ongoing day-to-day
"-current" development continues in the trunk, while changes to
the potential-release-tag may be pulled-up only by a "release engineer".
Generally only important bug fixes, rather than new features, are pulled up.

At some point the releng folks are satisfied that the branch is ready
to be tarred up as an actual release, and out goes the latest non-CVS version.

Likewise, critical fixes can be pulled up into older already-released
branches, for the benefit of people who deliberately run older releases
for stability or other reasons.  

	Sean.