Date: Thu, 23 Apr 1998 14:18:51 -0600 From: Nate Williams <nate@mt.sri.com> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: shimon@simon-shapiro.org, current@FreeBSD.ORG Subject: Re: A CAM of worms Message-ID: <199804232018.OAA11026@mt.sri.com> In-Reply-To: <199804231753.LAA26658@narnia.plutotech.com> References: <XFMail.980423065707.shimon@simon-shapiro.org> <199804231753.LAA26658@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > My exceptions to the proposed plan: > > > > * No migration path; The is no mechanism to migrate at all. We need a > > way to have the same system boot either way. We need a mechanism to > > maintain source for the old systems and switch back. > > There is certainly a migration path. Run a CAM kernel or don't. Must > developers I know have plenty of space to store two sys trees. As I > have stated to Julian several times, I will not polute the CAM code > with #ifdefs, or gratuitously rename controller driver file names or > "config names" just so you can build a kernel both ways. IMHO, with that attitude you can take the CAM stuff and go play somewhere else. Part of being a 'team effort' means making compromises so that everyone can work together. Alienating the entire -current code-base with no backwards path to do upgrade of local changes might be easier for you, but it's a nightmare for anyone that isn't intimately familiar with how the CAM stuff is written, which affects everyone but you. > If you want the code to go on a branch first, fine by me, but it is my > intention to only put the code into CVS at all once the minimum amount > of device support acceptable to users of current has been developed > and tested. Minimum acceptable w/out giving people who don't fit into the group is unacceptable. Nate 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?199804232018.OAA11026>