Date: Mon, 18 Feb 2002 10:25:23 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Robert Watson <rwatson@FreeBSD.ORG> 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: <200202181825.g1IIPNe26719@apollo.backplane.com> References: <Pine.NEB.3.96L.1020218130420.69361t-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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!
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 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.
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
:
:
:On Mon, 18 Feb 2002, Matthew Dillon wrote:
:
:> :With all do respect, I'd like to ask you to hold off for a couple of days
:> :until John is back in communication again from his travel to/from BSDCon.
:> :Over BSDCon he was talking about committing it within the next four days,
:>
:> With all due respect, every time I've tried to work on a subsystem in
:> current someone somewhere has had patches sitting around for months
:> that hadn't been comitted. NO WORK WILL GET DONE if John has half the
:> subsystems in current locked up with patches he hasn't committed.
:
:We're not talking about a lock. We're talking about common sense and
:courtesy. Since you seem to be impervious to polite requests, let me try
:again.
:
:<core hat on>
:Do not commit these changes until you have coordinated with John Baldwin.
:</core hat off>
:
:Please make use of basic and common courtesy: hold off on committing this.
:It's not a big thing. There's no rush. John is probably in transit right
:now on his way back to the east coast from attending BSDCon. If it was
:really important, you could have brought it up at the developer summit
:when he talked about the very patch we're now discussing. If it was
:really important, you would wait and talk with him about it when he gets
:back into communication. It's really not that hard. This request is now
:being made formally as a core team member.
:
:> John can synchronize his stuff when he gets back. It should not be a big
:> deal, these are whole subroutines that are being adjusted and he can
:> simply remove the elements of his patch set related to those subroutines.
:> The patches are very simple. Besides, I doubt John instrumented his
:> code with mtx_lock_giant() and with the amount of Giant-pushdown work
:> slated for the next few weeks that is going to be necessary to make
:> tracking down bugs possible.
:
:Have you looked at his Perforce branch?
:
:Let's look carefully at what you said before: you claimed that he (a)
:couldn't have done the work because the KSE pieces weren't there, and (b)
:he should have committed long ago because it was holding you up.
:
:(1) If he couldn't have done it because the pieces were there, he should
: obviously not have committed it. The reason he hadn't committed it
: was precisely because the pieces weren't there (I've been asking him
: to commit it for weeks, and he has pointed out every time that there
: were races that couldn't be closed because the KSE pieces weren't
: there).
:
:(2) Have you e-mailed him asking him to commit it, or letting him know he
: was holding you up? Have you made any attempt to review his
: work-in-progress?
:
:Robert N M Watson FreeBSD Core Team, TrustedBSD Project
:robert@fledge.watson.org NAI Labs, Safeport Network Services
:
:
Matthew Dillon
<dillon@backplane.com>
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?200202181825.g1IIPNe26719>