From owner-freebsd-current Sat Dec 7 10:23:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA03378 for current-outgoing; Sat, 7 Dec 1996 10:23:37 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA03371 for ; Sat, 7 Dec 1996 10:23:33 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA14481 for ; Sat, 7 Dec 1996 19:23:31 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA20272 for freebsd-current@FreeBSD.org; Sat, 7 Dec 1996 19:23:31 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id TAA21315 for freebsd-current@FreeBSD.org; Sat, 7 Dec 1996 19:18:54 +0100 (MET) From: J Wunsch Message-Id: <199612071818.TAA21315@uriah.heep.sax.de> Subject: Re: cvs commit: src/include utmp.h To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 7 Dec 1996 19:18:54 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <22065.849978642@time.cdrom.com> from "Jordan K. Hubbard" at "Dec 7, 96 09:10:42 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > Breaking backward compatibility to ourselves is IMHO a Bad Thing. I > > volunteer to write that tool (i think it's not a big deal anyway), but > > where should it go to? > > Ah, that's the harder part of the solution, isn't it? :-) > > Upgrades in general are poorly handled and always have been. To > really support this properly would require several enhancements to our > release building and installation systems: You are right. I've also though about it an hour ago, while thinking about parts of a particular installation that might be moved off to another place later: while the upgrade installation will painlessly create the new files, it will leave the old files in their stale location. Nobody will ever notice that they are stale, well unless somebody tries to edit them and wonders why his changes are not in effect at all... What about a `whiteboard' directory in CVS? Some place where everybody could append his notes at the end of a file? When it's release-build time, someone (:-) of the releng crew can pick it up, and make some sense for the upgrade procedure out of it... At least, this will ensure it won't be forgotten. What about $CVSROOT/src/upgrade/3.0/...? With a file named `Whiteboard' in each of these directories, as well as e.g. a file named `upgrade_wtmp.c' in our current case? We still need to address more of Jordan's list, of course, but this looks at least like a starting point to me, without preventing future more elegant solutions. What do people think about it? Of course, i also don't mind if there were a file `ReleaseNotes' in this directory, where people who commit more important new stuff (like entire new drivers, Posix support, etc.) append a note of this event, so another (or the same :) member of the releng team can compose the final RELEASENOTES file for the next release... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)