FreeBSD has serious problems with focus, longevity, and lifecycle

Eitan Adler lists at
Wed Jan 18 01:11:35 UTC 2012

On Tue, Jan 17, 2012 at 7:16 PM, Igor Mozolevsky <igor at> wrote:

> Seriously, WTF is the point of having a PR system that allows patches
> to be submitted??! When I submit a patch I fix *your* code (not yours
> personally, but you get my gist). No other project requires a
> non-committer to be so ridiculously persistent in order to get a patch
> through.

It takes time to review and test patches. There are a lot of people
that think "it only takes 30 seconds to download the patch, apply, and
commit."  This is just not true.

When I take PRs committers
1) Download the PR
2) Read the surrounding code sufficiently to understand what it does
3) Read the patched code to find the bug
4) Read the patch to see if it fixes the bug
5) Ensure that it is the most appropriate way to fix the bug
6) Apply the patch and test the affected issue.
7) Find the person who wrote the original code (or at least one other
person) and have them review it
    - this person usually goes through steps 1-6 too.
8) Apply the patch to head and commit
9) Verify the changes are correct didn't cause any regressions
10) MFC to stable[789]

And this assumes the patch was perfect, there really was a bug, and
everyone thinks things through properly.  The process take anywhere
from half an hour for obvious fixes to multiple days  in addition to
the committer's work, school, and family obligations..

Being persistent sometimes gives the committer the motivation to go
through all those steps.  As a part of the "bugbusting" team I've
taken quite a few bugs and been the "annoying persistent" person for
other people. As a result I've closed quite a few bugs.

> Such system is plainly wrong---it simply discourages people from
> sending "this works for me"(TM) fixes.

Yes and no. The system is bad, it shouldn't take 5 years to commit a
correct patch, but at the same time "this works for me patches" still
need to go through all of the above.

>  The committers have to realise
> three things: they can and do write broken code now and then, most
> people who write patches to help the fBSD along don't have the time to
> become full time committers (otherwise they'd already be, right?), and
> there's only so many times one is willing to bang their head against a
> wall with no results---as Einstein pointed out "Insanity: doing the
> same thing over and over again and expecting different results"...

And we need to work to find ways to fix issues while still ensuring
that the above steps are followed.

> I'm not saying that responding to reasonable requests from people who
> are in the process of testing and committing the patch, but expecting
> the end-users to chase committers to have a fix included is plainly
> wrong!..

I agree, and we need to work to find systematic solutions to correct
patches waiting for someone to take a look without compromising the
quality checks committers (should) do.

If you have ideas to make this process easier or more efficient we are
all eager to hear them. I am especially interested to know what *I*
could do to help speed things along in areas I don't know well enough
to commit to.

Eitan Adler

More information about the freebsd-hackers mailing list