From owner-cvs-all Mon Mar 25 13:27: 1 2002 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1CDD737B419; Mon, 25 Mar 2002 13:26:34 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g2PLQX482425; Mon, 25 Mar 2002 13:26:33 -0800 (PST) (envelope-from dillon) Date: Mon, 25 Mar 2002 13:26:33 -0800 (PST) From: Matthew Dillon Message-Id: <200203252126.g2PLQX482425@apollo.backplane.com> To: John Baldwin Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_prot.c References: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :On 23-Mar-2002 dillon@FreeBSD.org wrote: :> Is there a reason you made this commit without : :> :> (1) notifying me and : :Err, I was not aware that you wished for explicit notification. : :> (2) not resolving the giant wrappers issue first. : :I attempted to do this by working on an instrumentation patch that would :compromise by allowing the instrumentation code I don't really agree with to be :in place while still preserving the final code flow of the syscalls, but since :you demonstrated zero openness to compromise I gave up on it and figured there :was no reason to waste my time further. : :> And, in fact, my commit would also have gotten getresuid() :> and getresgid() out from under Giant, which your commit hasn't :> done. : :Hmm, I missed merging those changes in. I'll fix that when I do the suser() :API change. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ Ok, this is long winded but I believe I am able to maintain a relatively civil tongue throughout. Though it may not feel that way to you I do consider this a team project. It's just that your idea of teamwork is very different from mine. I generally don't give a damn who does a commit, as long as the commit gets done, but I do care about the timing. Moving the project forward as a whole is what matters most to me, and that infers many things: It infers a certain degree of short-term ownership of material under active developmnent. It infers being able to hold up another developer for a short period of time if a conflict arises. For example, you might say to Julian 'Hey Julian, could you hold off your stage X work for two days so I can commit Y before my patches become totally unmergable?'. Thats reasonable. But team work also infers not unnecessarily intefering or stalling another developer's work. You could have held me off for a week if you'd asked. But holding off someone else's work for an arbitrary, unspecified period of time, or for trivial reasons (like Jake and his tabbing complaints)... that is NOT team work, that is NOT moving the project forward, that is simply being selfish. This project isn't about ownership, it's about getting the work done. This project is not about setting things in stone, it's about trying things out. It's about being maleable. Perhaps my single largest complaint in regards to your oversight is that, as far as I can tell, the entire project is set in stone in your head, in P4, and in your documentation. Direction is useful, but being inflexible is detrimental to the project. This project is not about having a single vision. It was NEVER about having a single vision. - In regards to kern_prot.c and critical*().... I think you are missing a big point here, John. Even though you dislike my instrumentation work as much as I dislike the stuff Kelly and you have worked up, the fact remains that: * It would not have interfered with your work in the least. * It was simple, straightforward, and easily removed later on. (my instrumentation work is designed to be easily removed later on!). It's not the number of lines of code that makes things easy or difficult here. I think you've missed this point big time. Adding code with the intention of removing it at some point in the future does not somehow make the code useless, or difficult, or improper, or an imposition. * You could easily have negotiated its removal a month or two down the line for the read-only ucred bits and it would have been no skin off your nose to let me do the commit 4 weeks ago. The fact is that my giant wrapper is well tested and proven, and here you are trying to stop any work using it in order to, completely from scratch, develop, test, and commit a different idea, arbitrarily stalling any sort of instrumentation that I am involved in. That is inappropriate. Regardless of the instrumentation, it is now quite clear that contrary to all the whining people did when I wanted to commit the kern_prot stuff 4 weeks ago, that it would not have effected or interfered with your own development efforts in the least. I repeatedly asked people to substantiate their objections and those people, including yourself, repeatedly refused to face the issue squarely. There turned out to be no API breakage and no inteference with your own work. Consider how little of your time would have been wasted. I can't imagine it would take more then 10 seconds for you to clean up your P4 responsitory to take into accounts the commits I could have made 4 weeks and can still make now. It certainly didn't take me more then ten seconds to merge your commit with my kern_prot.c! All I care about is that the work get INTO the tree, I don't care who does it. I *DO* care *WHEN*, however. Now consider how much of my time you've wasted by stalling the development work I was and am keen on doing for over 4 weeks, as well as unnecessarily stalling testing by the larger development community... I think if you calculate the time lost to myself and to the communnity as a whole and time wasted by yourself that you would find that simply allowing the commit 4+ weeks ago would have been the most reasonable course of action. I am not counting flying arguments here, I am simply counting development and testing time lost to the project. Even now you appear to be missing the point. Why not simply allow me to commit the getresuid() and getresgid() code today? Why insist on forcing me to wait another unspecified period of time for you to include it with other work? It took you 4 weeks to do a partial commit of kern_prot.c, how long is it going to be before you get to getresuid()? I mean, come on... either you are going to commit this cleanup today or tomorrow yourself, which is perfectly acceptable to me, or you should let me do it now. I have it all tested and ready to go in. What is the big problem about not letting me put this work in now? - When I commit something, it is not set in stone. I have no problem making modifications and follow-up commits. I prefer to commit things piecemeal, because it moves the project forward more quickly and squeezes the bugs out more quickly and easily. But I do take issue with core project work being stalled indefinitely for reasons that could just as easily be resolved after a commit, and especially for reasons that are not substantiated by facts but instead are opinions from people who haven't even bothered to read the patch. From this point on I am going to be diplomatic, but firm. If you have a problem with my work I expect it to be (a) non-trivial and (b) substantiated by facts, and if it isn't I will say so in no uncertain terms. And the issue will either be resolved or it will be dropped. - I am extremely disappointed in core's actions to date. I have repeatedly asked that these issues be decided on technical merit. I have repeatedly asked people to substantiate their claims in regards to perceived difficulties with my commits. Not one person has been able to substantiate any claim. They've all evaporated, leaving a minor complaint about syntax and the placement of two procedures in MI vs MD files. All the stuff about interference and API breakage... poof, gone. Because it never existed in the first place. Instead, Core has made vague statements essentially giving a single person VETO power over substantially the entire -current kernel. I would like to see Core clarify this statement in regards to what is reasonable and what is not, because under the current terms no substantive reason is required for John to veto anything. Does core actually believe it is reasonable for the technical lead to arbitrarily stall a commit without having to say when it would be unstalled? Or use trivial or unsubstantiated reasons to prevent work from going in? Is 'I don't want this optimized yet' sufficient to prevent a developer's work from going into the tree? Hell, I don't even agree with the concept of having a technical lead covering so much of the -current kernel.. SMPng *IS* current for all intents and puposes. It touches everything. A VM lead, or a filesystem lead, or a SCSI lead... sure. But SMPng? It makes no sense at all. All the big pieces are either already in place or well enough defined that development progresses pretty much under its own steam now. The position is already not relevant to development (and I'm not talking about my own development here, I am talking about ALL the development that is going on). Case in point: Jeff's UMA work requires discussion but certainly does not require a technical lead. Julian's work requires discussion but not a SMPng technical lead. Julian is effectively his own technical lead for KSEs. VM work is a group effort, requiring discussion but not requiring a technical lead. I can't think of a single major subsystem that requires a SMPng technical lead. It was an ill-thought, ill-conceived notion of core's. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message