From owner-freebsd-current Tue May 5 02:16:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA03255 for freebsd-current-outgoing; Tue, 5 May 1998 02:16:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA03195 for ; Tue, 5 May 1998 02:15:57 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.7] (user10.dataplex.net [208.2.87.10]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id EAA29356; Tue, 5 May 1998 04:15:40 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199805050239.UAA28033@mt.sri.com> References: <19980504203155.41473@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 May 1998 04:12:18 -0500 To: Nate Williams From: Richard Wackerbarth Subject: Re: Proposal: Kernel API version -> param.h Cc: Steve Price , Eivind Eklund , current@FreeBSD.ORG, Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:39 PM -0500 5/4/98, Nate Williams wrote: >> You might want to also take a look at what Richard >> Wackerbarth proposed in conf/6346, as it falls into >> a similar category as this. > >Except that Richard's proposal has been shot-down as incomplete, and he >isn't interested in fixing it or hearing that it's broken. My PR 6346 proposal is complete and provides a "work around" to distributing a datestamp from the CVS tree itself. As for that portion of things, I have previously stated that I was unable to make CVS fail as you indicated. Although I requested additional clarification, you never provided me with an sample case where it did. I do not consider the automatic removal of the stamp from unauthorized branches to be a "failure", as such. The behavior is exactly the same that I see if a human intentionally removes something from the tree. (CVS complains until you fix the inconsistent state) As for your argument that it is desirable to have more of the mechanism for adding new branches automated, I agree that that would be a nice addition. However, it is not necessary for the scheme to work within its design scope. I might have more interest in fuller development of the scheme if I saw any willingness to have it adopted. You, Nate, have already proven that you will raise the requirements in midstream so that you can have an excuse to keep my contributions out. Perhaps Eivind will be willing to give my proposal a less biased reception. There are three distinct parts to the system. (1) The part in conf/6346 should be adopted first. It does not affect the CVS tree. (2) The "branched changed" flagging done in the commit scripts does not do anything to the CVS tree. It simply creates a token to allow the deamon to know that it should do something. (3) We could always implement a regular cvs update to avoid tricking the system into avoiding the ever-growing file. In any case, John Polstra needs to sign off on the shortcut before we actually use it in production. (4) Then, if the scheme is actually useful, we can worry about improving the scripting of the installation of new branches. I am already convinced that this scheme should NOT be fully automatic. I have already seen "cockpit error" that would have cause your proposed automaton to "do the wrong thing". IMHO, for the major tree, I think we still need the checks and balances that go with a separate authorization rather than a purely automated one. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message