Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Jan 1999 17:02:55 +0000 (GMT)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Sren Schmidt <sos@sos.freebsd.dk>
Cc:        Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>, sos@FreeBSD.ORG, msmith@FreeBSD.ORG, current@FreeBSD.ORG
Subject:   Re: syscons update - when?
Message-ID:  <Pine.BSF.4.01.9901061701080.391-100000@herring.nlsystems.com>
In-Reply-To: <199901061132.MAA05593@sos.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.01.9901061701080.391-100000>