From owner-cvs-usrsbin Wed Aug 16 22:34:43 1995 Return-Path: cvs-usrsbin-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA21111 for cvs-usrsbin-outgoing; Wed, 16 Aug 1995 22:34:43 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA21104 ; Wed, 16 Aug 1995 22:34:33 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id WAA22231; Wed, 16 Aug 1995 22:33:15 -0700 From: "Rodney W. Grimes" Message-Id: <199508170533.WAA22231@gndrsh.aac.dev.com> Subject: Re: cvs commit: src/usr.sbin/sendmail - Imported sources To: peter@haywire.dialix.com (Peter Wemm) Date: Wed, 16 Aug 1995 22:33:14 -0700 (PDT) Cc: CVS-commiters@freefall.FreeBSD.org, cvs-usrsbin@freefall.FreeBSD.org In-Reply-To: from "Peter Wemm" at Aug 17, 95 01:15:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3386 Sender: cvs-usrsbin-owner@FreeBSD.org Precedence: bulk > > On Wed, 16 Aug 1995, Peter Wemm wrote: > > > Date: Wed, 16 Aug 1995 21:40:04 -0700 > > From: Peter Wemm > > To: CVS-commiters@freefall.FreeBSD.org, cvs-usrsbin@freefall.FreeBSD.org > > Subject: cvs commit: src/usr.sbin/sendmail - Imported sources > > > > peter 95/08/16 21:40:03 > > > > Branch: usr.sbin/sendmail 1.1.1 > > Log: > > Import Sendmail v8.6.12, onto the CSRG(!) branch. > > A seperate commit to fix the conflicts wil follow. > > > > Status: > > > > Vendor Tag: CSRG > > Release Tags: v8_6_12 > > > > C src/usr.sbin/sendmail/src/conf.c > > C src/usr.sbin/sendmail/src/daemon.c > > C src/usr.sbin/sendmail/src/deliver.c > > C src/usr.sbin/sendmail/src/readcf.c > > > > 4 conflicts created by this import. > > Use the following command to help the merge: > > > > cvs checkout -jCSRG:yesterday -jCSRG src/usr.sbin/sendmail > > FYI: Rod and I agonized over what to do about these.. We tried all sorts > of neat tricks, including directly editing the RCS files, but we were > unable to get what we needed. Peter come extreamly close, and I must thank him for the long hours he put in trying. > In the end, we decided "screw it!" - and just go with the flow and patch > it up this time (and again should 8.6.13 come out before 8.7 (which is due > RSN)). Some times you gota do what you gota do to get some things off your plate so you can go work on other things. > We *will* fix this properly for 8.7 - but that will probably be by > re-importing it afresh, into a different area, with some cute Makefiles, > or some other mechanism yet to be thought of. FYI, this screams of wanting more details, this is a purposeful leak, Peter, Paul Traina, and myself are off looking at alternative mechanisms and paradigms to try and solve some of the problems we have with the current maintenance of vendor code. We have some ideas (thanks to Peter!), some definite goals (thanks to Paul!), and some definite direction (thats what I am trying to do). Once we go play with these ideas, goals, and directions off in some dirty dusty cvs repositories we intend to present a white paper to this group that will allow us to move forward into implementing what we have learned, and hopefully solve our vendor branch problems once and for all. We can't say a whole lot about it until we have a chance to go play with it, so to give us a chance to move on to the larger (and, IMHO, more important) problem of how to get _all_ of the code fixed we are going to use the old paradigm of how the code had been currently maintained to fix sendmail and bind, and those are 2 seriously sore spots. The same most likely goes for at and atrun, but Peter might have a trick up his sleeve her yet, or at least, from his last email it indicated he might. I see a lot of calling for ``gee, great, how about this next'', if we drag the resource off to fix todays problems and don't leave some of them for working on tomorrows problems, we will end up snow balled and never get to tomorrows problems until they are staring us straight in the face as todays problems :-(. {God, thats hard to read, can you understand what I was trying to say???} -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD