From owner-freebsd-current Wed Jan 6 09:57:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13733 for freebsd-current-outgoing; Wed, 6 Jan 1999 09:57:20 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13720; Wed, 6 Jan 1999 09:57:10 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by nlsystems.com (8.9.1/8.8.5) with SMTP id RAA16414; Wed, 6 Jan 1999 17:04:20 GMT Date: Wed, 6 Jan 1999 17:02:55 +0000 (GMT) From: Doug Rabson To: Sren Schmidt cc: Kazutaka YOKOTA , sos@FreeBSD.ORG, msmith@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: syscons update - when? In-Reply-To: <199901061132.MAA05593@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 6 Jan 1999, Sren Schmidt wrote: > It seems Kazutaka YOKOTA wrote: > > As I announced before, reorganization of syscons code is under way and > > I intend to commit changes in three stages. > > > > Stage 1: keyboard driver split > > Stage 2: video driver split, splash screen > > Stage 3: other reorganization > > > > The new code has been running on my -current box for quite a while. > > > > Now, -stable branch date is coming up. The question is how much > > change we should commit before the branch? We can defer commit after > > the branch and later backport the new code from -current to -stable. > > However, there is a snug. > > > > At stage 1 and 2, the users will be forced to change their kernel > > configuration files because keyboard and video drivers become separate > > from syscons. Such change is probably too much, if suddenly > > introduced to -stable well after the branch. > > > > So, probably our options are: > > > > a) Commit stage 1 and 2 changes now. Stage 3 changes may be backported > > to -stable from -current later. > > b) Don't commit any changes now, but commit them to -current after the > > branch. Don't backport the changes to -stable at all. When the next > > branch (3.1-STABLE?) comes, let it have the new code. > > > > I prefer the option a). But, I have to expect rough ride after > > commits, as changes of this scale will have many initial glitches... > > I prefer option a) also. If option a) also includes repo-copying the code out of the i386 tree into an architecture neutral place, then I think that is the right way to go. I'd rather not perform that kind of code movement after the split. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message