Date: Tue, 26 Feb 2002 15:46:53 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: Alfred Perlstein <bright@mu.org>, Julian Elischer <julian@elischer.org>, Jake Burkholder <jake@locore.ca>, Matt Dillon <dillon@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 exception.s genassym.c machdep.c mp_machdep.c mpapic.c swtch.s vm_machdep.c src/sys/i386/include cpufunc.h pcb.h src/sys/i386/isa apic_vector.s clock.c icu_vector.s intr_machdep.c intr_machdep.h npx.c src/sys/kern ... Message-ID: <Pine.NEB.3.96L.1020226153002.28921U-100000@fledge.watson.org> In-Reply-To: <p05101405b8a19884061e@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Feb 2002, Garance A Drosihn wrote: > At 11:34 AM -0800 2/26/02, Alfred Perlstein wrote: > >I do think that we need to make this a bit more process driven for > >fairness. > > > >How about from now on if _anyone_ raises an objection to changes > >because "they have something better in a local tree", that person > >will have one or two weeks to polish that code up and get it in the > >tree, otherwise the other work goes in. Maybe not one or two weeks > >but a firm deadline for the changes in progress to be put in. > > I think we (as a project) *must* do this, in the interest of fairness. > The point is not whether "Matt Wins" or "JMB Wins", the point is how to > run a project which has a few hundred developers. You can not run it > with everyone having some big uber-commit off in their own little > private world (or maybe a world with two or three other developers). > You have to get code out where everyone can see it, and react to it. > Commit it, and move on to the next thing. > > We are not talking about anyone's good intentions here, we are trying to > develop a few million lines of code without driving each other crazy. > Consider us "The Odd Couple", except that there is two hundred of us > instead of just two. I am 100% certain that both JMB and Matt are > trying their best to get the best possible result for the project. It's > just that one is using a method which is more practical for a project of > this size and interest-level. I think it's important to note that there's been a fundamental mis-understanding about what the two "don't commit that" requests have had to do with. My first request was specifically that coordination with John be attempted before committing the change, since he had done identical work and was preparing it for commit. I didn't say it couldn't eventually be committed, simply that this was a group project, and in a group project there is a *fundamental* assumption of coordinating with with others. The second request, not initiated by myself, was to not commit the most recent changes on several grounds. Bruce requested that Matt not commit it until John had had a chance to review it. John observed that it conflicted with the current proposed model, and suggested how it might be modified to better match the model. Jake requested it be backed out because it was still under discussion. None of these had anything to do with not committing something resembling it eventually either: they had everything to do with working with others. In fact, I don't think John made any claim of having something like Matt's patch in his local tree: he instead worried about its interaction with some patches to implement changes that have been discussed pretty extensively throughout SMPng. The important observation here is that when a change is contentious, it doesn't hurt to not commit it immediately, but to wait. In fact, that's a pretty basic assumption, one I'd personally (with and without core hat) hold all committers to. It is fundamentally necessary to coordinate with others on a large group project. The project cannot succeed without that coordination, or without the assumption that if there's disagreement on a change, there be the opportunity to discuss it. "I'm committing it tomorrow even if there are objections" is not an acceptable perspective. In group projects, there will be objections, and sometimes, those objections can be overruled, but in practice the path by which you get to that over-ruling is very important. Yes, John probably didn't expose enough of his on-going efforts on SMPng. On the other hand, bringing it all to a head with "I'm going to commit things now" is not the way to raise those problems. Instead, posts to -smp or -arch to talk about general direction, lack of patch-posting, or whatever, would have been far more appropriate. Changes in development model happen as a result of feedback, and they're not instantaneous. Likewise, it should be expected that round trip times on communication may be several days: not everyone is online at all times. This isn't a license to not respond to e-mail in order to ignore comments or questions, but it is a plea for reasonable behavior. The FreeBSD core team expects basic civility from all committers, at all times. We also expect a best faith effort to work with other committers, especially once contention has been identified. This can and must be a learning process: we can't lay it all out in rules, and we can't expect everyone to get everything right the first time. We can, and do, expect people to learn from their mistakes. We should discuss how P4 does or does not impact successful communication. In fact, I attempted to start a thread on freebsd-current to talk about guidelines and recommendations on the topic of how to prevent this entire problem for occurring. Unfortunately, only phk replied to it, despite apparent interest by many. If you have serious feedback on this issue, in particular recommendations regarding how to address the problems we've run into, I would appreciate it if you'd respond to the post. I can repost it if necessary. 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.1020226153002.28921U-100000>