Date: Tue, 26 Feb 2002 13:03:14 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Garance A Drosihn <drosih@rpi.edu>, Alfred Perlstein <bright@mu.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.BSF.4.21.0202261248580.94891-100000@InterJet.elischer.org> In-Reply-To: <Pine.NEB.3.96L.1020226153002.28921U-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Feb 2002, Robert Watson wrote:
> 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 problem is that there is no way to know when the discussion on the
mailing lists has reached the point where a commit can happen.
In linux it's easy.. Linus says "ok.. I'll commit that then".
In FreeBSD someone has to give in. This is not a good way to
make people in the project feel. (" I had to give up.
He just types too fast" or "He's in core").
We NEEEEEEED to have an architectural review board or something.
When we voted to vote for a core we decided it was NOT an architectural
review board, but we also agreed that we might look at having one in
the future.
>
> 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.
Bruce, last I saw was saying. "that looks about right" after Matt
incoproated a lot of his comments and ideas. John waved his hands around a
bit but didn't have anything much to say except "It's incomaptible with
what I have". (COMMIT JOHN!!!!) Jake just stuck his oar in as an
intersted bystander.
>
> 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.
>
The core group now needs to make a decision on whether this code can go
in, and if not, give a good TECHNICAL reason why not.
This decision must be forthcoming within about 48 hours or core is falling
down on the job.
It also needs to make a decision as to how we get around the
"dog in the manger" problem in the future. I suggest that
in all cases it should not be possible for person A to stall Person B
indefinitly when person B has good work to do.
I would also like to have core take a stand that having code in P4 isn NOT
the same as publishing it. P4 is an aid to the developer to do PRIVATE
work. As long as the work is in P4 it is up to the developer to
keep it in sync with -current. From the project's perspective
work in P4 doesn't exist. I keep my KSE work up-to date with
-current without complaints becasue I know that is the way it is.
(I will however be chacking it in on a branch today into CVS
so people can actually SEE it.) I will use P4 to help me do this..
> 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.
Maybe only he got it.. I never saw it.. please re post it.
>
>
> 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.BSF.4.21.0202261248580.94891-100000>