Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 May 1998 04:12:18 -0500
From:      Richard Wackerbarth <rkw@dataplex.net>
To:        Nate Williams <nate@mt.sri.com>
Cc:        Steve Price <sprice@hiwaay.net>, Eivind Eklund <eivind@yes.no>, current@FreeBSD.ORG, <jdp@polstra.com>
Subject:   Re: Proposal: Kernel API version -> param.h
Message-ID:  <l03130302b17480be79a3@[208.2.87.7]>
In-Reply-To: <199805050239.UAA28033@mt.sri.com>
References:  <Pine.OSF.3.96.980504185209.3913A-100000@fly.HiWAAY.net> <19980504203155.41473@follo.net> <Pine.OSF.3.96.980504185209.3913A-100000@fly.HiWAAY.net>

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



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