From owner-cvs-sys  Sun Jul 30 19:00:05 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id TAA01481
          for cvs-sys-outgoing; Sun, 30 Jul 1995 19:00:05 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id SAA01457
          ; Sun, 30 Jul 1995 18:59:58 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA01919; Sun, 30 Jul 1995 18:59:25 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507310159.SAA01919@gndrsh.aac.dev.com>
Subject: Re: cvs commit: src/sys/kern tty.c
To: bde@zeta.org.au (Bruce Evans)
Date: Sun, 30 Jul 1995 18:59:25 -0700 (PDT)
Cc: bde@zeta.org.au, davidg@Root.COM, CVS-commiters@freefall.cdrom.com,
        cvs-sys@freefall.cdrom.com
In-Reply-To: <199507302155.HAA18270@godzilla.zeta.org.au> from "Bruce Evans" at Jul 31, 95 07:55:13 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1339      
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

> 
> >   There have been 14 commits to tty.c since it was branched for 2.1. I'm
> >slowly beginning to think that we should consider taking the bulk of the fixes
> >rather than doing this piece-meal. Many of the fixes are important and most of
> >them seem to be intertwined. Some of the changes are matched with changes to 
> >sio.c and other serial drivers...so these changes must be brought in, too.
> >   I'd like to hear other opinions about this.
> 
> They are actually layered so that the drivers are usable after each commit.
> This has been tested more than I originally intended because it has taken
> so long to commit everything.  Each layer of course may depend on the
> intertwining of the previous layers, so it would be easier to bring in
> everything.  Wait for several more layers anyway.

With that last sentence I would say this stuff all waits for 2.2, release
branches should no longer ``wait'' for fixes to come in, as there are
always things to fix.  Document the problems as known bugs, and even ear
mark them as being worked on/fixed in 2.2, but don't start to drag the
release out.

We should be cutting alpha about now if I recall the schedule correctly.


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD