Date: Mon, 18 Feb 2002 13:48:29 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Poul-Henning Kamp <phk@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_time.c Message-ID: <Pine.NEB.3.96L.1020218132710.69361C-100000@fledge.watson.org> In-Reply-To: <200202181825.g1IIPNe26719@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Feb 2002, Matthew Dillon wrote: > I am just trying to work on the fucking operating system. Every single > fucking subsystem that I've fucking tried to work on in -current has > been fucking locked down for arbitrary periods of time. Certain people > have their fingers sticky with half a dozen subsystems worth of patches > all at once. I appreciate the time you're spending on FreeBSD; I value the input you provided at the developer summit. I'm not asking you not to work on the system. I'm asking you to work with John. > There is NO FOCUS, and as a consequence it is preventing other developers, > such as Julian and I, from doing even the simplest things to the tree > or it is forcing us to partially commit work and then wait for an arbirary > period of time before being able to complete it. At this rate even if > I dedicate my time to -current, we won't have anything done for another > two fucking years! I disagree with the assertion that there is no focus. I do agree with a more general assertion that we could all work harder to communicate about where we're going. However, I think that we have to accept occasional waiting as a pre-requisite for working on group projects. This is not a race to commit first so as to avoid conflicts in your own tree. This is a cooperative activity to create something as a group. The reason I'm sticking firm on this point is that I truly believe that we're better off if we wait a few days and get John's input on this. It may be that he says "Yes, go ahead and commit, I'll deal with the conflicts". Or it may be that he says "I was holding off because I ran into a crash on sparc64 that's related to the change, and I want to run another test run when I get back to Atlanta: don't commit the ucred changes because there are known problems". Whatever it is he's going to say, he needs to have the chance to say that, and it's in the interest of the project as a whole for us to provide that kind of opportunity. We can discuss the focus issue at length in another forum, or even in this forum in another thread. Part of my goal in funding and orchestrating the Developer Summit was to help refine the notion of focus, and provide a vehicle for that focus to be discussed and honed. But my definition of focus is more associated with working together as a group towards common goals, and my belief is that I'm actualy reinforcing a move towards focus by asking you to hold off on committing. > Should I just not bother at all? People have been screaming at me to > work on current. Well, here I am! And I can't work on a goddamn thing > because I can't commit a goddamn thing for days. It is a phenominal waste > of my time. These changes cannot be done in parallel, they have to be > down top-down. I'm very interested in having you work on -CURRENT. Work can be done in parallel often enough, and yes, there are times when it can't. That's precisely why I'm asking you to coordinate with John. The response to those times is coordination, not committing anyway. This maps pretty well from the SMP model: when things can't be done in parallel, you use synchronization primitives. :-) > I don't use perforce and I don't intend to use it. I think it's a > MISTAKE for people to use it. It is hard enough for current developers > to work in -current. Now we have to deal with half-stale patches in > perforce as well as current? Perforce is YOUR pain, not mine. No one is requiring you to use Perforce. However, using Perforce would allow you to get more insight into what John has in progress, and make coordinating easier. If you don't use Perforce, then you're back where we were before Perforce (no more, no less): you can't see what other people have in their trees. The perforce repository is, btw, exported via cvsup on cvsup10, so if you prefer using CVS to get to this stuff, it's very easy to do. In fact, most of the people working on TrustedBSD use cvsup10 to access the head of the tree, for precisely that reason: it gives them access to the development tree, but they don't have to use the p4 software to do it. Perforce is a tool to allow us to work together in ways that we couldn't have previously. It allows for tighter synchronization when doing extensive local development: I can keep a version history while efficiently pulling in changes from the central tree. It isn't a substitute for normal communication on mailing lists, patchsets, etc. It's not required to work on FreeBSD, or even required to work on FreeBSD in an effective manner. Julian's approach of using P4 for development, code-sharing, and integration, but posting patchsets during the review process sounds to me like a fairly model way to take this forward, and I encourage others to do the same where it makes sense for them. > Now as a core member you can prevent me from committing, but I will tell > you right now that this is FUCKED UP. I have the time now, the ability > now, and the focus to push Giant down into major portions of existing > system calls. I have it relative to -current current, I have tested it, > and I goddamn want to commit it! Matt, I didn't wave the core stick until you told me you were going to commit it anyway, despite several requests to not commit it. If someone else had been making these requests rather than me, I would have come in waving the core stick now asking you to hold off. And if I'm wrong for waving the core stick, I'm sure I'll be told about it extensively, and we'll have the opportunity to discuss that also. However, my feeling was that waiting a few days is a price that we can afford to pay, in the name of working more effectively. On the topic of committing because it compiles and you've tested it: it's not about whether you've compiled it and tested it. It's about the relationship between the work you're doing, and the work John is doing. Please don't take this personally: it's not about the fact that it's Matt Dillon asking to commit these changes. It's about the fact that I saw an e-mail saying someone was going to commit changes without holding off for coordination, when it had been clearly pointed out that this might be in conflict with work done by another developer: work that you were aware of because it was explicitly discussed at the developer summit which you attended, and when you had been explicitly told that holding off would be a good idea. Believe me when I say that I am also eager for John to move more stuff from his p4 branch into the main tree, and I'm eager for us to push down Giant in all those places. I also, believe it or not, want to see -CURRENT move ahead more agressively with regards to the SMPng changes, and the fact that you have time to invest to make this happen makes me feel very pleased, since that will mean we can move forward faster. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020218132710.69361C-100000>