From owner-cvs-sys  Sun Jul 30 18:51:45 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id SAA01351
          for cvs-sys-outgoing; Sun, 30 Jul 1995 18:51:45 -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 SAA01344
          ; Sun, 30 Jul 1995 18:51:41 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id SAA01837; Sun, 30 Jul 1995 18:51:03 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507310151.SAA01837@gndrsh.aac.dev.com>
Subject: Re: cvs commit: src/sys/kern tty.c
To: davidg@Root.COM
Date: Sun, 30 Jul 1995 18:51:02 -0700 (PDT)
Cc: bde@zeta.org.au, CVS-commiters@freefall.cdrom.com,
        cvs-sys@freefall.cdrom.com
In-Reply-To: <199507301844.LAA00185@corbin.Root.COM> from "David Greenman" at Jul 30, 95 11:44:55 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: 2031      
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

> 
> >>bde         95/07/30 06:52:57
> >
> >>  Modified:    sys/kern  tty.c
> >>  Log:
> >>  Don't swap the queue headers to implement concatenation of the
> >>  queues for TIOCSETA[W].  Swapping an even number of times broke
> >>  the queue resource limits.  This would have broken CRTSCTS flow
> >>  control if the clist slush list was used up.
> >>  
> >>  Don'concatenate the queues for TIOCSETA[W] if one of the queues
> >>  has a resource limit of 0.  Concatenation would cause a panic if
> >>  one of the queues is nonempty and the other is limited to length
> >>  0.  This may have caused panics in PPPDISC.
> >>  
> >>  Wake up readers after all transitions of ICANON.  When ICANON is
> >>  turned off it is quite likely that characters will become available
> >>  to be read.
> >>  
> >>  Reduce indentation near these changes.
> >
> >This change should go in 2.1.
> 
>    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.

IMHO this is a mixture of bug fixes from 1.x, and new work.  Since it
is intertwined segregating what is well tested and known code from new
and unknown code is very hard.

Without 2 to 4 weeks of heavy testing it is a bad idea to bring new code
into a release branch.  Just ask anyone who has ever done a release.

Then #1 cause for release slippage is bug fixing new code brought in
after branching.

I would classify this as more than bug fixes, it is more like major reworking
to fix the design flaws.  Something that should wait for a 2.2 release.

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