Date: Tue, 5 May 1998 11:46:08 -0500 From: Richard Wackerbarth <rkw@dataplex.net> To: Nate Williams <nate@mt.sri.com>, <jkh@time.cdrom.com> Cc: Steve Price <sprice@hiwaay.net>, Eivind Eklund <eivind@yes.no>, current@FreeBSD.ORG Subject: Re: Proposal: Kernel API version -> param.h Message-ID: <l03130305b174e71083df@[208.2.87.7]> In-Reply-To: <199805051405.IAA29890@mt.sri.com> References: <l03130302b17480be79a3@[208.2.87.7]> <Pine.OSF.3.96.980504185209.3913A-100000@fly.HiWAAY.net> <19980504203155.41473@follo.net> <199805050239.UAA28033@mt.sri.com> <l03130302b17480be79a3@[208.2.87.7]>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:05 AM -0500 5/5/98, Nate Williams wrote: >> I do not consider the automatic removal of the stamp from unauthorized >> branches to be a "failure", as such. > >There are no such things as 'authorized/unauthorized' branches in CVS. >You will break people who use branches, which is unacceptable. You even >admit now that branches will cause problems with your solution, and I >don't even have to drag out the email I sent. :) > >You're already made your case for me, so I'll ignore further email on >the topic. As far as I can tell, you have no actual complaint that the code fails to work as designed. This simply boils down to a disagreement over the appropriate design behavior when a user creates a new branch. It is my contention that my policy is an acceptable design policy. (If the branch maker does not obtain "administrative approval", the new file that he has caused to be added will be removed by the administrator) As a policy, I routinely delete large files that sit in public temporary areas for too long. If the user wishes to have the file treated otherwise, he must make administrative arrangements to allow it to be saved somewhere else. Similarly, if he wishes to have the facility support timestamps on a new branch, the branch maker must take the additional step of having the new branch approved for the service. Otherwise, the unauthorized file will be yanked. I see no difference. The error that I see from CVS is simply informing the user that he did not take all of the necessary steps. He must either "get approval", delete his reference to the file, or live with the error message. I admit that the fact that, presently, this policy is "designed into the product" may limit the utility of it for some installations. However, I do not see that it is necessarily a bad policy. In fact, I happen to think that it is generally a good policy for something like the master cvs tree. Just as you restrict those who are allowed to commit to the tree, why cannot you also restrict those who are allowed to add branches which receive this service. Further, this entire datestamp service (the net result to the end user) is untested in practice. Even if it works to the best design we can dream up, the "marketplace" may not care whether or not it exists. Why is it appropriate for you to veto a "test marketing". If the test shows that it is a desired service, FreeBSD, Inc. can then decide on their administrative policy for it and we can streamline the implementation of that policy. I can see far too many design details that might wish to be "tweeked." I cannot justify producing "production line" tools to test a concept prototype. The "one-off" techniques of the model shop are adequate to get things started. I repeat my complaint that there is a double standard occurring. I have seen many times that an "insider" gets to try something that is unfinished. In fact, the "it won't even pass the 'compiles' test" gets raised. Yet, you insist that I implement the "deluxe" version without your even giving my "demo" version a chance to be seen and/or tried by others. 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?l03130305b174e71083df>