Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Jan 2008 18:35:24 -0600
From:      linimon@lonesome.com (Mark Linimon)
To:        Dominic Fandrey <kamikaze@bsdforen.de>
Cc:        freebsd-current@freebsd.org
Subject:   Re: FreeBSD's problems as seen by the BSDForen.de community
Message-ID:  <20080110003524.GB5188@soaustin.net>
In-Reply-To: <478556AD.6090400@bsdforen.de>
References:  <478556AD.6090400@bsdforen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
I appreciate the fact that you took the time to write this post and
raise serious issues in a non-confrontational manner.

On Thu, Jan 10, 2008 at 12:20:13AM +0100, Dominic Fandrey wrote:
> Even minimal I/O load on a hard disk suffices to lock up whole systems.
> Posts on the mailinglists current and stable have often been answered
> with denial or have simply been ignored.

The responses on the mailing lists can indeed vary in quality.  My own
experience is that many of the key FreeBSD developers respond fairly
well -- when they've got time to do so.  Some exceptions exist.  But
I don't think any one person is working on amd64 to the exclusion of i386.
Perhaps that is what it would take.

Other than trying to identify individuals whose responses are doing more
harm than good, I don't have any suggestions here.

> What we think might be a solution to the regression problem, would be
> the establishing of a Regressions Team, similar to other teams like the
> Security Team.

Unfortunately it requires volunteers to constitute such a thing.  I've
been trying to come up with ideas on how to get more people involved
in what we would consider 'maintainence' activities, but I've yet to
make an impact.  A few people have expressed interest in helping to go
through the PR backlog, but the big shortage is committers who are
willing to work with them on such unglamorous tasks.  (I am working on
a proposal to at least make it less frustrating to do so, but I don't
want to tie that into this thread.)

Having said that, I would join such a team and try to work with it.

> PRs remain unanswered or the reporters are told that the regressions
> they report do not exist.

We clearly have a disconnect on PRs.  More come in than we have any way
to handle.  This is clearly most distressing when the PRs contain
patches and/or test cases.  Again, I'm open to ideas on how to set up
something where more people can participate.

I've tried to flag certain PRs with '(regression)', fwiw, which is
necessary but clearly insufficient.

> To solve the performance problems it appears to us, that a guide to
> tracking performance problems or a performance test suite is required.

I think that's 2 separate issues.  I had not thought much about trying
to categorize certain PRs as 'performance' but it really does make sense.
I will try to work on this issue.

There is actually work on performance tests, but it goes on behind the
scenes and is not publicized.  (The jump in performance for most
workloads on i386-7 is due to the efforts of many individuals who have
been relentlessly testing MySQL, Postgres, Bind, and other real-world
workloads since the 7 branch was created.  Kris, the other respondent in
this thread, is one of the people doing a great deal of work on this.)
Some of this is documented at http://wiki.freebsd.org/Performance.  If
there's more specific information that needs to be added there, let me
know off-list.

There is also the work at http://wiki.freebsd.org/PerformanceTracker,
which I do not know the state of.  This sounds encouraging.

FreeBSD is mostly driven by individual efforts (we are, however, seeing
more interest from corporations, some of whom see network performance
as a key issue).  To some extent it's more "interesting" to do new work
than do maintainance work; this is a classical software engineering
problem.  Again, I'm completely open to suggestions on how to get more
people interested in working in this area.

mcl



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