From owner-freebsd-current Thu Mar 7 7:37:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 685DC37B429; Thu, 7 Mar 2002 07:36:44 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.6/8.11.5) with ESMTP id g27FcKI56152; Thu, 7 Mar 2002 08:38:20 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200203071538.g27FcKI56152@aslan.scsiguy.com> To: Matthew Dillon Cc: John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem In-Reply-To: Your message of "Wed, 06 Mar 2002 21:33:44 PST." <200203070533.g275Xii64069@apollo.backplane.com> Date: Thu, 07 Mar 2002 08:38:20 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > The API is intended for the stage-2 commit. The stage-1 commit > is intended to do all the 'hard stuff' in as straightforward > a manner as possible. The sysctl / option you talk about here > existed in my patch set 2 and a half weeks ago. The API and getting it right is more important than the "hard stuff". Its not as fun, but the API will outlive the code (consider the next arch, and the next). It may take more of your time due to discussion and feedback to get the API in place, but that's part of the cost of collaboration. > I really wish you people would at least read the patch and commit > message before you comment on it. I didn't have to read the patch to know that there were concerns and on-going discussion about the API. In this instance, the issues are not large and can be remedied quickly - all the more reason for the discussion to take place before the commit. I didn't have to read the patch to know that you didn't seem to care about getting the API "right" before commiting the code. The API was "something to be cleaned up later". "If you have problems with my API, I'll even help merge your changes into mine, but I need to commit now." "Lets discuss this after the commit." This project is not about a race to commit. [Perhaps my viewpoint here is a bit different then some seeing as the CAM stuff was 1.5 years old by the time it was committed to the tree. I know all about painful merge conflicts.] I didn't have to read the patch to know that you would only remove your commit if someone could point to specific defects in the "hard part" of your submission. The "hard part", how it works, and whether it contained any bugs or not was not the real issue. This is why you and John were talking right past each other. Don't get me wrong, Matt. I don't think you should be unduley held off from committing either. From my perspective of the discussion so far, other than the delay for John to get back home from BSDcon, we could have finished the discussion about the API and committed this stuff a week ago if the focus wasn't on how you were personally wronged, or "John is holding up the whole tree", or "my changes are correct, my changes are correct". All of the above may be true, but focusing on the particular events instead of the *process to avoid them recurring in the future* will only lead to more frustration and you wanting to work on -stable instead of -current, etc. You're a good engineer Matt. You've shown before that you can colloborate and coordinate with others in this project. The only issue is how that colloboration takes place, and the *process* for getting things done. If the process makes it twice as hard for us to get things done, then it's broken. In that case, *attack the process*, not the person. The process can and will change but only if we set aside "personal indignity" (why should I have to put up with this crap!?!?) and attack our problems and goals as engineers. Sometimes the flare-ups in FreeBSD remind me of the middle-east. Each side accuses the other side of "starting it", or "having the blame". In reality, both sides were jerks, own portions of the blame, and have concentrated on continuing the conflagration rather than mitigating it. I hope we have a better perspective on reality. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message