Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Nov 2002 02:38:32 -0800
From:      David Schultz <dschultz@uclink.Berkeley.EDU>
To:        Nate Lawson <nate@root.org>
Cc:        Wilko Bulte <wkb@freebie.xs4all.nl>, Terry Lambert <tlambert2@mindspring.com>, hackers@FreeBSD.ORG
Subject:   Re: dgb driver update
Message-ID:  <20021105103832.GA57295@HAL9000.homeunix.com>
In-Reply-To: <Pine.BSF.4.21.0211041112520.7400-100000@root.org>
References:  <20021104130717.A27977@freebie.xs4all.nl> <Pine.BSF.4.21.0211041112520.7400-100000@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Nate Lawson <nate@root.org>:
> The best way is to send a pr and then followup on mailing lists as
> appropriate or perhaps by contacting the maintainer.  The PR provides
> history for a given problem and patch and the followup initiates action on
> behalf of the committers.  It's important to get someone to take up the
> "responsible" field before any action can happen.

This idea works if the components in question have maintainers.
The bits that are in most need of patching do not, so obvious
one-line patches go un-committed because nobody thinks themselves
to be familiar enough with the code.

> BTW, the number of PRs is not totally the fault of committers.  I've been
> scanning through the DB with about 50% of my FreeBSD-time and fixing
> things that I find there.  However, it has taken about 3x as long as I
> expected to commit a patch because almost all of them are very incomplete
> and actually are more a suggestion on an area that needs improvement, not
> a fix.

I applaud you, but the PR problem won't be solved until the other
90% of the committer base chips in as well.

It is *not* always the case that closing PRs requires extra work.
On several occasions, people have reinvented the wheel and
committed patches identical (or nearly so) to ones I submitted six
months earlier.  I'm sure others have noticed the same thing.
It's even worse when the patch that's actually applied is bogus,
as in the case of some changes to renice(1).  I don't have a whole
lot of free time, but when I spend some of it getting something
right, I don't care to wait for months and then have to explain to
someone else why they got it wrong.

Admittedly the majority of PRs, even some of the ones with
patches, are nontrivial to address.  But so little attention is
given to the PR database that even the straightforward PRs get
overlooked.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021105103832.GA57295>